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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49113 in the body.
You can then email your comments to 49113 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: bug-guix <at> gnu.org
Subject: aarch64-linux-gnu cross-compiler fails to build [core-updates]
Date: Sat, 19 Jun 2021 12:05:39 +0200

[Message part 1 (text/plain, inline)]

X-Debbugs-CC: 48913 <at> debbugs.gnu.org
X-Debbugs-CC: ludo <at> gnu.org	

Ludovic Courtès schreef op vr 18-06-2021 om 11:33 [+0200]:
> Maxime Devos <maximedevos <at> 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.

[68ahjhkcq8ck07cagsx90qy8g0860y-gcc-cross-aarch64-linux-gnu-8.5.0.drv.bz2 (application/x-bzip, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 49113 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: 49113 <at> debbugs.gnu.org
Subject: Re: bug#49113: aarch64-linux-gnu cross-compiler fails to build
 [core-updates]
Date: Sun, 20 Jun 2021 14:17:14 +0200

[Message part 1 (text/plain, inline)]

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.

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 49113 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 49113 <at> debbugs.gnu.org
Subject: Re: bug#49113: aarch64-linux-gnu cross-compiler fails to build
 [core-updates]
Date: Sat, 03 Jul 2021 18:12:46 +0200

Hi,

Maxime Devos <maximedevos <at> 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’.

Message #14 received at 49113 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 49113 <at> debbugs.gnu.org
Subject: Re: bug#49113: aarch64-linux-gnu cross-compiler fails to build
 [core-updates]
Date: Sun, 04 Jul 2021 22:33:34 +0200

Hello,

Ludovic Courtès <ludo <at> gnu.org> skribis:

> Maxime Devos <maximedevos <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.