[-- Attachment #1: Type: text/plain, Size: 7704 bytes --] I tested this on 683eb7c5b118440001b89944563603a39fc2ac05. The problem does not occur on master. How to reproduce: # --target=aarch64-linux-gnu also fails, but that's another issue ./pre-inst-env guix build --target=i686-linux-gnu hello --keep-failed Error message (during 'configure' phase): checking for i686-linux-gnu-gcc... i686-linux-gnu-gcc checking whether the C compiler works... no configure: error: in `/tmp/guix-build-hello-2.10.drv-0/hello-2.10': configure: error: C compiler cannot create executables See `config.log' for more details error: in phase 'configure': uncaught exception: %exception #<&invoke-error program: "/gnu/store/kpkbyk7jlw6n5z3jkbia9mcr0bhflzbf-bash-minimal-5.1.8/bin/bash" arguments: ("./configure" "CC_FOR_BUILD=gcc" "CONFIG_SHELL=/gnu/store/kpkbyk7jlw6n5z3jkbia9mcr0bhflzbf-bash-minimal-5.1.8/bin/bash" "SHELL=/gnu/store/kpkbyk7jlw6n5z3jkbia9mcr0bhflzbf-bash-minimal-5.1.8/bin/bash" " --prefix=/gnu/store/wmkbla5nncld4rdyqkwc9lw9kzypvdab-hello-2.10" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--host=i686-linux-gnu") exit-status: 77 term-signal: #f stop-signal: #f> phase `configure' failed after 3.1 seconds From 'config.log': configure:4014: checking whether the C compiler works configure:4036: i686-linux-gnu-gcc conftest.c >&5 i686-linux-gnu-ld: cannot find -lgcc_s i686-linux-gnu-ld: cannot find -lgcc_s collect2: error: ld returned 1 exit status configure:4040: $? = 1 configure:4078: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU Hello" | #define PACKAGE_TARNAME "hello" | #define PACKAGE_VERSION "2.10" | #define PACKAGE_STRING "GNU Hello 2.10" | #define PACKAGE_BUGREPORT "bug-hello@gnu.org" | #define PACKAGE_URL "http://www.gnu.org/software/hello/" | #define PACKAGE "hello" | #define VERSION "2.10" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:4083: error: in `/tmp/guix-build-hello-2.10.drv-0/hello-2.10': configure:4085: error: C compiler cannot create executables Issue: Somehow, the C cross-compiler does not find "libgcc_s". Look at CROSS_LIBRARY_PATH and LIBRARY_PATH in /tmp/[...]/environment-variables, we have (line breaks added): export CROSS_LIBRARY_PATH= /gnu/store/glc86jl13yj70k2h4mm3pqwff351mxav-glibc-cross-i686-linux-gnu-2.33/lib: /gnu/store/wk761j8qqq7yf949wyxjgcbqxcx574nf-glibc-cross-i686-linux-gnu-2.33-static/lib export LIBRARY_PATH= /gnu/store/w6ydl1fjxhkc69cs90vmg3g48vwcy59w-binutils-cross-i686-linux-gnu-2.36.1/lib: /gnu/store/lv8zj6sl3fc6db2ljq10haba3sfhvq6b-bzip2-1.0.8/lib: /gnu/store/hhg5z17xyfj7zvg864br41nsj6g918ym-xz-5.2.5/lib: /gnu/store/pnj9pzyk4ajs9a245krx5l4sp4p8xwyk-file-5.39/lib: /gnu/store/0amam2n0vjb62zh6jssb9pjnwcf302hw-gawk-5.1.0/lib: /gnu/store/3fasjd1jnnm6vhyff5wb3kkahnxzbl49-binutils-2.36.1/lib: /gnu/store/mf4kmmhka2dagnna6a0h4fciz5ijaxsn-glibc-2.33/lib: /gnu/store/dj2p4mwp6gwbx8fpd6gqsj2c307mm6sp-glibc-2.33-static/lib: /gnu/store/dxplmvm0xf8z968m3lbwzizc95h9nldc-glibc-utf8-locales-2.33/lib When I run "ls -l" on each of these directories, I notice none of these have a "libgcc_s.so" file. So it's not very surprising GNU ld (via GCC) cannot find it. Now, where could we find "libgcc_s.so"? I found it in /gnu/store/6b4sgmqd3nrajbx47zryi0n4s08sfrb6-gcc-cross-i686-linux-gnu-8.5.0/i686-linux-gnu/lib/ By explicitely passing "-L/gnu/store/6b4sgmqd3nrajbx47zryi0n4s08sfrb6-gcc-cross-i686-linux-gnu-8.5.0/i686-linux-gnu/lib/", the C program compiles. So, I guess we need to add that directory to CROSS_LIBRARY_PATH. Or ... * Shouldn't this be present in the spec file? Let's test. /gnu/store/6b4sgmqd3nrajbx47zryi0n4s08sfrb6-gcc-cross-i686-linux-gnu-8.5.0/bin/i686-linux-gnu-gcc -dumpspecs Output (only a part shown) *lib: %{!mandroid|tno-android-ld:-L/gnu/store/glc86jl13yj70k2h4mm3pqwff351mxav-glibc-cross-i686-linux-gnu-2.33/lib %{!static:-rpath=/gnu/store/glc86jl13yj70k2h4mm3pqwff351mxav-glibc-cross-i686-linux-gnu- 2.33/lib %{!static-libgcc:-rpath=/gnu/store/53i7hxqwf3apvz77bsapjvrigjiimg29-gcc-cross-i686-linux-gnu-8.5.0-lib/i686-linux-gnu/lib -lgcc_s}} %{pthread:-lpthread} %{shared:-lc} %{!shared:%{profile:- lc_p}%{!profile:-lc}};:%{shared:-lc} %{!shared:%{profile:-lc_p}%{!profile:-lc}} %{!static: -ldl}} Curiously, /gnu/store/53i7hxqwf3apvz77bsapjvrigjiimg29-gcc-cross-i686-linux-gnu-8.5.0-lib/i686-linux-gnu/lib is actualy present! Let's compile in verbose mode. $ i686-linux-gnu-gcc -v conftest.o Output: > Using built-in specs. > COLLECT_GCC=i686-linux-gnu-gcc > COLLECT_LTO_WRAPPER=/gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0/libexec/gcc/i686-linux-gnu/8.5.0/lto-wrapper > Target: i686-linux-gnu > Configured with: > Thread model: posix > gcc version 8.5.0 (GCC) > COMPILER_PATH=/gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0/libexec/gcc/i686-linux-gnu/8.5.0/:/gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0/libexec/gcc/i686-linux-gnu/8.5.0/:/gnu/store/[...]- gcc-cross-i686-linux-gnu-8.5.0/libexec/gcc/i686-linux-gnu/:/gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0-lib/lib/gcc/i686-linux-gnu/8.5.0/:/gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0- lib/lib/gcc/i686-linux-gnu/ > CROSS_LIBRARY_PATH=/gnu/store/[...]-glibc-cross-i686-linux-gnu-2.33/lib/:/gnu/store/[...]-glibc-cross-i686-linux-gnu-2.33-static/lib/:/gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0- lib/lib/gcc/i686-linux-gnu/8.5.0/:/gnu/store/[...]-glibc-cross-i686-linux-gnu-2.33/lib > COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=pentiumpro' > /gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0/libexec/gcc/i686-linux-gnu/8.5.0/collect2 -plugin /gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0/libexec/gcc/i686-linux-gnu/8.5.0/liblto_plugin.so -plugin-opt=/gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0/libexec/gcc/i686-linux-gnu/8.5.0/lto-wrapper -plugin-opt=-fresolution=/tmp/guix-build-hello-2.10.drv-0/ccxP5sep.res -plugin-opt=-pass- through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --eh- frame-hdr -m elf_i386 -dynamic-linker /gnu/store/[...]-glibc-cross-i686-linux-gnu-2.33/lib/ld-linux.so.2 /gnu/store/[...]-glibc-cross-i686-linux-gnu-2.33/lib/crt1.o /gnu/store/[...]-glibc-cross-i686- linux-gnu-2.33/lib/crti.o /gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0-lib/lib/gcc/i686-linux-gnu/8.5.0/crtbegin.o -L/gnu/store/[...]-glibc-cross-i686-linux-gnu-2.33/lib -L/gnu/store/[...]-glibc- cross-i686-linux-gnu-2.33-static/lib -L/gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0-lib/lib/gcc/i686-linux-gnu/8.5.0 -L/gnu/store/[...]-glibc-cross-i686-linux-gnu-2.33/lib conftest.o -lgcc --as- needed -lgcc_s --no-as-needed -L/gnu/store/[...]-glibc-cross-i686-linux-gnu-2.33/lib -rpath=/gnu/store/[...]-glibc-cross-i686-linux-gnu-2.33/lib -rpath=/gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0- lib/i686-linux-gnu/lib -lgcc_s -lc -lgcc --as-needed -lgcc_s --no-as-needed /gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0-lib/lib/gcc/i686-linux-gnu/8.5.0/crtend.o /gnu/store/[...]-glibc-cross-i686- linux-gnu-2.33/lib/crtn.o > i686-linux-gnu-ld: cannot find -lgcc_s > i686-linux-gnu-ld: cannot find -lgcc_s What went wrong here? I took a look at the folowing entry in CROSS_LIBRARY_PATH: /gnu/store/[...]-gcc-cross-i686-linux-gnu-8.5.0-lib/lib/gcc/i686-linux-gnu/8.5.0/. In this directory, there is a "libgcc.a", but not a "libgcc_s.so"! So, we have a static libgcc library, but not a dynamic libgcc_s library! To be investigated ... or worked around by tweaking CROSS_LIBRARY_PATH ... [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1295 bytes --] Some digging. Currently, there exists a gcc-7-cross-toolexeclibdir.patch. It is applied to gcc 6 and gcc 7 but not gcc 8. Looking at 'cross-gcc' in 'gnu/packages/cross-base.scm', we have (patches (append (origin-patches (package-source xgcc)) (append (cond ((version>=? (package-version xgcc) "8.0") (search-patches "gcc-8-cross-environment-variables.patch")) ((version>=? (package-version xgcc) "6.0") (search-patches "gcc-7-cross-toolexeclibdir.patch" "gcc-6-cross-environment-variables.patch")) (else (search-patches "gcc-cross-environment-variables.patch"))) (cross-gcc-patches xgcc target)))) The patches for gcc-8+ were introduced in 83b0a7f41bccb7b46f1d443e80a22c61a3ff92bc. Seems like we forgot to include gcc-7-cross-toolexeclibdir.patch! I tried to add this patch, but the patch doesn't apply to the gcc 8 code, so I guess I'll have to port it to gcc 8. So I cloned the git repository of GCC, and it appears toolexeclibdir is currently in GCC 8! But perhaps a mistake has been made somewhere ... to be investigated. (Now looking at libgcc/configure.ac) [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 636 bytes --] Maxime Devos schreef op di 08-06-2021 om 10:41 [+0200]: > I tested this on 683eb7c5b118440001b89944563603a39fc2ac05. > The problem does not occur on master. > > How to reproduce: > > # --target=aarch64-linux-gnu also fails, but that's another issue > ./pre-inst-env guix build --target=i686-linux-gnu hello --keep-failed I have found a solution: passing --with-slibdir to GCC's configure script. Not sure if that's the proper solution though. GNU Hello now builds succesfully! I'll test with a few more packages later and then ‘formally’ submit the patch (after writing a commit message). Greetings, Maxime. [-- Attachment #1.2: the-diff.diff --] [-- Type: text/x-patch, Size: 1951 bytes --] diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm index 9487ac9238..6e64450b13 100644 --- a/gnu/packages/cross-base.scm +++ b/gnu/packages/cross-base.scm @@ -7,6 +7,7 @@ ;;; Copyright © 2019, 2020, 2021 Marius Bakke <marius@gnu.org> ;;; Copyright © 2019 Carl Dong <contact@carldong.me> ;;; Copyright © 2020 Mathieu Othacehe <m.othacehe@gmail.com> +;;; Copyright © 2021 Maxime Devos <maximedevos@telenet.be> ;;; ;;; This file is part of GNU Guix. ;;; @@ -169,12 +170,23 @@ base compiler and using LIBC (which may be either a libc package or #f.)" )) ;; Install cross-built libraries such as libgcc_s.so in - ;; the "lib" output. + ;; the "lib" output. (But see below.) ,@(if libc `((string-append "--with-toolexeclibdir=" (assoc-ref %outputs "lib") "/" ,target "/lib")) '()) + ;; At least for GCC 8.0, libgcc_s.so and libstdc++.so + ;; are not installed in the location specified in + ;; --with-toolexeclibdir so GCC will not find it + ;; when cross-compiling, say, GNU Hello. + ;; + ;; Work-around by specifying slibdir. + ,@(if (and libc (version>=? (package-version xgcc) "8.0")) + `((string-append "--with-slibdir=" + (assoc-ref %outputs "lib") + "/" ,target "/lib")) + '()) ;; For a newlib (non-glibc) target ,@(if (cross-newlib? target) '("--with-newlib") [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
Hi,
Maxime Devos <maximedevos@telenet.be> skribis:
> ./pre-inst-env guix build --target=i686-linux-gnu hello --keep-failed
“i686-linux-gnu” is not among the supported cross-compilation triplets,
which are roughly those that appears in (@ (gnu ci) %cross-targets).
It’s rarely useful to cross-compile to i686-linux-gnu because you can
just build natively on an x86_64-linux-gnu machine:
guix build -s i686-linux hello
All this to say, I don’t think we should spend energy on the
i686-linux-gnu cross toolchain.
WDYT?
Ludo’.
Maxime Devos <maximedevos@telenet.be> skribis:
> I have found a solution: passing --with-slibdir to GCC's configure
> script. Not sure if that's the proper solution though. GNU Hello
> now builds succesfully! I'll test with a few more packages later
> and then ‘formally’ submit the patch (after writing a commit message).
Could you check whether aarch64-linux-gnu or armhf-linux-gnueabihf (say)
have the problem, and whether this patch addresses it?
Thanks,
Ludo’.
[-- Attachment #1: Type: text/plain, Size: 1417 bytes --] Ludovic Courtès schreef op vr 18-06-2021 om 11:33 [+0200]: > Maxime Devos <maximedevos@telenet.be> skribis: > > > I have found a solution: passing --with-slibdir to GCC's configure > > script. Not sure if that's the proper solution though. GNU Hello > > now builds succesfully! I'll test with a few more packages later > > and then ‘formally’ submit the patch (after writing a commit message). > > Could you check whether aarch64-linux-gnu or armhf-linux-gnueabihf (say) > have the problem, and whether this patch addresses it? This patch (passing --with-slibdir) doesn't actualy fully work (when cross-compiling to i686-linux-gnu from a x86_64-linux), as libstdc++ is not installed in the right place (and other stuff like libusan, but those are less critical IMHO). I sent a more complete (and hackier) patch as part of the patch series for implementing cross-compilation in Meson (not really the right place, I know, but it's hard to test cross-compilation when the cross-compiler is broken), see [PATCH v3 core-updates 36/37: Fix cross-compiler for i686-linux-gnu] (https://issues.guix.gnu.org/49025>. I'll send a mail to bug#49025 asking people to respond about that patch at bug#48913, to keep things separate. I'll test whether aarch64-linux-gnu and armhf-linux-gnueabihf have the same problem and whether the patch (from bug#48913) addresses it. Greetings, Maxime. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 3499 bytes --] X-Debbugs-CC: 48913@debbugs.gnu.org X-Debbugs-CC: ludo@gnu.org Ludovic Courtès schreef op vr 18-06-2021 om 11:33 [+0200]: > Maxime Devos <maximedevos@telenet.be> skribis: > > > I have found a solution: passing --with-slibdir to GCC's configure > > script. Not sure if that's the proper solution though. GNU Hello > > now builds succesfully! I'll test with a few more packages later > > and then ‘formally’ submit the patch (after writing a commit message). > > Could you check whether aarch64-linux-gnu or armhf-linux-gnueabihf (say) > have the problem, and whether this patch addresses it? aarch64-linux-gnu has a problem, but it appears to be a different problem than the issue of i686-linux-gnu, so I'm starting a new issue. (Note: I don't yet have rebased my tree on latest core-updates. I've heard there are some GCC 10 updates now, maybe that will change something?) I attached a build log when compiling with revised patch from #49025 (patch 36/37). The build fails. Relevant tail of log (during building of libgcc_s.so): aarch64-linux-gnu-ld: skipping incompatible /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so when searching for -lc [ previous line 2 times repeated ] aarch64-linux-gnu-ld: cannot find -lc aarch64-linux-gnu-ld: skipping incompatible /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so when searching for -lc [ previous line 2 times repeated ] collect2: error: ld returned 1 exit status make[2]: *** [Makefile:985: libgcc_s.so] Error 1 This also happened before the patch. Some tests: $ aarch64-linux-gnu-objdump -x /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so > aarch64-linux-gnu-objdump: /gnu/store/.../libc.so: file format not recognized $ cat /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so > /* GNU ld script > Use the shared library, but some functions are only in > the static library, so try that secondarily. */ > OUTPUT_FORMAT(elf64-little) > GROUP ( /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so.6 /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu- 2.33/lib/libc_nonshared.a AS_NEEDED ( /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/ld-linux-aarch64.so.1 ) ) $ aarch64-linux-gnu-objdump -x /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so.6 > /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so.6: file format elf64-littleaarch64 > /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so.6 > architecture: aarch64, flags 0x00000150: > HAS_SYMS, DYNAMIC, D_PAGED > start address 0x00000000000215a8 Maybe the *_s.o files have a different architecture? $ aarch64-linux-gnu-objdump -x *_s.o > unwind-sjlj_s.o: file format elf64-littleaarch64 > unwind-sjlj_s.o > architecture: aarch64, flags 0x00000011: > HAS_RELOC, HAS_SYMS > start address 0x0000000000000000 > private flags = 0x0: > [and other output] The file format (elf64-littleaarch64) is the same between libc and libgcc. The architecture ("aarch64") is also the same. But the flags are different! (0x00000150 vs 0x00000011). Maybe that's the issue, or it is harmless? To be investigated ... Greetings, Maxime. [-- Attachment #1.2: 68ahjhkcq8ck07cagsx90qy8g0860y-gcc-cross-aarch64-linux-gnu-8.5.0.drv.bz2 --] [-- Type: application/x-bzip, Size: 371142 bytes --] [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1: Type: text/plain, Size: 842 bytes --] Ludovic Courtès schreef op vr 18-06-2021 om 11:33 [+0200]: > Could you check whether aarch64-linux-gnu or armhf-linux-gnueabihf (say) > have the problem, and whether this patch addresses it? The second triplet appears to be invalid. $ ./pre-inst-env guix build hello --target=armhf-linux-gnueabihf > checking target system type... Invalid configuration `armhf-linux-gnueabihf': machine `armhf-unknown' not recognized > configure: error: /gnu/store/yqmhgw1fwmb9x498d4mpq5y046zcv3lw-bash-minimal-5.1.8/bin/bash ./config.sub armhf-linux-gnueabihf failed > error: in phase 'configure': uncaught exception: [...] (during the build of binutils-cross-armhf-linux-gnuabihf) $ ./pre-inst-env guix build hello --target=arm-linux-gnueabihf # ^ replacing armhf with arm > [ plenty of output, not yet completed ] Greetings, Maxime. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 580 bytes --] Ludovic Courtès schreef op vr 18-06-2021 om 11:33 [+0200]: > Could you check whether aarch64-linux-gnu or armhf-linux-gnueabihf (say) > have the problem, and whether this patch addresses it? I tried ./pre-inst-env guix build hello --target=arm-linux-gnueabihf with the revised patch, but it fails building /gnu/store/l6yhx9axhfbdmk7cm8cf9mql4h8mrqmc-glibc-cross-arm-linux-gnueabihf-2.33.drv. I'll update to latest core-updates and retry with and without the patch. Build log attached. There is an ICE, and dmesg doesn't note any OOM errors. Greetings, Maxime. [-- Attachment #1.2: yhx9axhfbdmk7cm8cf9mql4h8mrqmc-glibc-cross-arm-linux-gnueabihf-2.33.drv.bz2 --] [-- Type: application/x-bzip, Size: 78864 bytes --] [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1: Type: text/plain, Size: 820 bytes --] About 0x00000150 vs 0x00000011: 0x00000150 means D_PAGED | DYNAMIC | HAS_SYM and 0x00000011 means HAS_SYMS | HAS_RELOC Here, (from bfd/bfd-in2.h in binutils sources) /* BFD is dynamically paged (this is like an a.out ZMAGIC file) (the linker sets this by default, but clears it for -r or -n or -N). */ #define D_PAGED /* BFD contains relocation entries. */ #define HAS_RELOC 0x1 /* BFD is a dynamic object. */ #define DYNAMIC 0x40 I believe this is a dead end. Writing "int r(void){return 0;}" to a.c and running "gcc -c -shared -fpic a.c" on my x86_64 and "objdump -x a.o", I see architecture: i386:x86-64, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x0000000000000000 (The flags are identical) Greetings, Maxime. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #1: Type: text/plain, Size: 824 bytes --] Ludovic Courtès schreef op vr 18-06-2021 om 11:32 [+0200]: > Hi, > > Maxime Devos <maximedevos@telenet.be> skribis: > > > ./pre-inst-env guix build --target=i686-linux-gnu hello --keep-failed > > “i686-linux-gnu” is not among the supported cross-compilation triplets, > which are roughly those that appears in (@ (gnu ci) %cross-targets). > > It’s rarely useful to cross-compile to i686-linux-gnu because you can > just build natively on an x86_64-linux-gnu machine: > > guix build -s i686-linux hello > > All this to say, I don’t think we should spend energy on the > i686-linux-gnu cross toolchain. > > WDYT? Agreed, closing. Though if someone has the same issue when building a cross-compiler from, say, aarch64 to i686, then I'd recommend reopening it. Greetings, Maxime. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 260 bytes --]
Hi, Maxime Devos <maximedevos@telenet.be> skribis: > aarch64-linux-gnu-ld: skipping incompatible /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so when searching for -lc > [ previous line 2 times repeated ] > aarch64-linux-gnu-ld: cannot find -lc > aarch64-linux-gnu-ld: skipping incompatible /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so when searching for -lc > [ previous line 2 times repeated ] > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile:985: libgcc_s.so] Error 1 As discussed on IRC, the problem seems to be that, when cross-compiling, the ‘OUTPUT_FORMAT’ bit in libc.so is wrong (“elf64-little” instead of “elf64-littleaarch64”). This, in turn, seems to be due to a regression in how glibc’s build machinery computes that value, which is fixed by this patch: https://sourceware.org/pipermail/libc-alpha/2021-July/128333.html I haven’t had feedback from upstream yet but I’ll apply it soonish in Guix as it does the job. Thanks, Ludo’.
Hello,
Ludovic Courtès <ludo@gnu.org> skribis:
> Maxime Devos <maximedevos@telenet.be> skribis:
>
>> aarch64-linux-gnu-ld: skipping incompatible /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so when searching for -lc
>> [ previous line 2 times repeated ]
>> aarch64-linux-gnu-ld: cannot find -lc
>> aarch64-linux-gnu-ld: skipping incompatible /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so when searching for -lc
>> [ previous line 2 times repeated ]
>> collect2: error: ld returned 1 exit status
>> make[2]: *** [Makefile:985: libgcc_s.so] Error 1
>
> As discussed on IRC, the problem seems to be that, when cross-compiling,
> the ‘OUTPUT_FORMAT’ bit in libc.so is wrong (“elf64-little” instead of
> “elf64-littleaarch64”). This, in turn, seems to be due to a regression
> in how glibc’s build machinery computes that value, which is fixed by
> this patch:
>
> https://sourceware.org/pipermail/libc-alpha/2021-July/128333.html
>
> I haven’t had feedback from upstream yet but I’ll apply it soonish in
> Guix as it does the job.
Pushed as 949ed7aae1e9418ea99f569efe6cb03349485508!
Ludo’.