/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: i386 architecture of input file /usr/lib/../lib/crti.o is incompatible with i386:x86-64 output /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: i386 architecture of input file /usr/lib/../lib/crtn.o is incompatible with i386:x86-64 output collect2: error: ld returned 1 exit status make[3]: *** [Makefile:992: libgcc_s.so] Error 1 make[3]: Leaving directory /var/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-gentoo-linux-musl/libgcc make[2]: *** [Makefile:16824: all-stage1-target-libgcc] Error 2 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0_musl_hardened-20200322-121503 ------------------------------------------------------------------- gcc-config -l: Available Python interpreters, in order of preference: [1] python3.7 [2] python3.6 [3] python2.7 (fallback) timestamp of HEAD at this tinderbox image: /var/db/repos/gentoo Sun Mar 22 10:14:20 UTC 2020 /var/db/repos/musl Sun Mar 22 03:12:57 UTC 2020 emerge -qpvO sys-devel/gcc [ebuild NS ] sys-devel/gcc-9.3.0 [9.2.0-r2] USE="(cxx) hardened nls nptl openmp (pie) (ssp) (-altivec) -d -debug -doc (-fixed-point) -fortran -go -graphite (-jit) (-libssp) -lto (-multilib*) -objc -objc++ -objc-gc (-pch) -pgo (-sanitize*) -systemtap -test -vanilla (-vtv*)"
Created attachment 624412 [details] emerge-info.txt
Created attachment 624414 [details] emerge-history.txt
Created attachment 624416 [details] environment
Created attachment 624418 [details] etc.portage.tbz2
Created attachment 624420 [details] logs.tbz2
Created attachment 624422 [details] sys-devel:gcc-9.3.0:20200322-112154.log.bz2
Created attachment 624424 [details] temp.tbz2
I'm a bit surprised to see gcc to fail build itself, but it's probably another manifestation of bug #675954
(In reply to Sergei Trofimovich from comment #8) > I'm a bit surprised to see gcc to fail build itself, but it's probably > another manifestation of bug #675954 assumption would be wrong in this case.
Another odd thing is this transition: > [ebuild NS ] sys-devel/gcc-9.3.0 [9.2.0-r2] USE="(cxx) hardened nls nptl openmp (pie) (ssp) (-altivec) -d -debug -doc (-fixed-point) -fortran -go -graphite (-jit) (-libssp) -lto (-multilib*) -objc -objc++ -objc-gc (-pch) -pgo (-sanitize*) -systemtap -test -vanilla (-vtv*)" According to 'man emerge' '*' means: '* suffix transition to or from the enabled state' 'multilib' change looks unexpected assuming both 9.2.0-r2 and 9.3.0 ebuilds use the same eclass and profile. Also, it's not very clear from the output, but build.log implies gcc ebuild comes from ::musl overlay and not gentoo: * Package: sys-devel/gcc-9.3.0 * Repository: musl The failure snippet implies that /usr/lib/crti.o is a 32-bit file: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: i386 architecture of input file `/usr/lib/../lib/crti.o' is incompatible with i386:x86-64 output Toralf, can you double-check it? That should be the output: $ file /usr/lib/crti.o /usr/lib/crti.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
How on earth are we starting out with a ::gentoo gcc and then switching to a ::musl gcc? It should be ::musl all along? Presently ::gentoo won't build properly under musl afaik... Any why is portage output not displaying repositories, or is that me always using --verbose options everywhere .. XD
Created attachment 625010 [details] emerge.log emerge log
The musl hardened was setup in the same way as musl(In reply to Sergei > > $ file /usr/lib/crti.o > /usr/lib/crti.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not > stripped $ chr img2/17.0_musl_hardened-20200322-121503 mr-fox ~ # file /usr/lib/crti.o /usr/lib/crti.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped mr-fox ~ # exit
wrong stage3 was used - my fault
