bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

[Maxime Devos]

[-- 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 --]

bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

[Maxime Devos]

[-- 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 --]

bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

[Maxime Devos]

[-- 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 --]

bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

[Ludovic Courtès]

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’.

bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

[Ludovic Courtès]

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’.

bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

[Maxime Devos]

[-- 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 --]

bug#49113: aarch64-linux-gnu cross-compiler fails to build [core-updates]

[Maxime Devos]

[-- 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 --]

bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

[Maxime Devos]

[-- 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 --]

bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

[Maxime Devos]

[-- 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 --]

bug#49113: aarch64-linux-gnu cross-compiler fails to build [core-updates]

[Maxime Devos]

[-- 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 --]

bug#48913: i686-linux-gnu cross-compiler cannot find libgcc_s [core-updates]

[Maxime Devos]

[-- 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 --]

bug#49113: aarch64-linux-gnu cross-compiler fails to build [core-updates]

[Ludovic Courtès]

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’.

bug#49113: aarch64-linux-gnu cross-compiler fails to build [core-updates]

[Ludovic Courtès]

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’.