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