I'm trying to build a toolchain for s390x (s390x-ibm-linux-gnu) using crossdev, but it fails reproducible at building GCC stage 2: ------------------------------------------------------------------- * crossdev version: 20240921 * Host Portage ARCH: amd64 * Host Portage System: x86_64-pc-linux-gnu (x86_64-pc-linux-gnu) * Target Portage ARCH: s390 * Target System: s390x-ibm-linux-gnu * Stage: 4 (C/C++ compiler) * USE=multilib: no * Target ABIs: s390x * binutils: binutils-[latest] * gcc: gcc-[latest] * headers: linux-headers-[latest] * libc: glibc-[latest] * CROSSDEV_OVERLAY: /home/share/gentoo/var/db/repos/local * PORT_LOGDIR: /home/share/gentoo/var/log/portage * PORTAGE_CONFIGROOT: /home/share/gentoo/ * Portage flags: _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - * getting sys-devel/binutils from /home/share/gentoo/var/db/repos/local * leaving metadata/layout.conf alone in /home/share/gentoo/var/db/repos/local _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - * Log: /home/share/gentoo/var/log/portage/cross-s390x-ibm-linux-gnu-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /home/share/gentoo/var/log/portage/cross-s390x-ibm-linux-gnu-gcc-stage1.log * Emerging cross-gcc-stage1 ... [ ok ] * Log: /home/share/gentoo/var/log/portage/cross-s390x-ibm-linux-gnu-linux-headers.log * Emerging cross-linux-headers ... [ ok ] * Log: /home/share/gentoo/var/log/portage/cross-s390x-ibm-linux-gnu-glibc.log * Emerging cross-glibc ... [ ok ] * Log: /home/share/gentoo/var/log/portage/cross-s390x-ibm-linux-gnu-gcc-stage2.log * Emerging cross-gcc-stage2 ... * error: gcc failed :( * * If you file a bug, please attach the following logfiles: * /home/share/gentoo/var/log/portage/cross-s390x-ibm-linux-gnu-info.log * /home/share/gentoo/var/log/portage/cross-s390x-ibm-linux-gnu-gcc-stage2.log.xz * /home/share/gentoo/var/tmp/portage/cross-s390x-ibm-linux-gnu/gcc*/temp/gcc-config.logs.tar.xz The actual build error is: /home/share/gentoo/var/tmp/portage/cross-s390x-ibm-linux-gnu/gcc-14.2.1_p20241026/work/build/./gcc/xgcc -B/home/share/gentoo/var/tmp/portage/cross-s390x-ibm-linux-gnu/gcc-14.2.1_p20241026/work/build/./gcc/ -B/home/share/gentoo/usr/s390x-ibm-linux-gnu/bin/ -B/home/share/gentoo/usr/s390x-ibm-linux-gnu/lib/ -isystem /home/share/gentoo/usr/s390x-ibm-linux-gnu/include -isystem /home/share/gentoo/usr/s390x-ibm-linux-gnu/sys-include -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fno-stack-clash-protection -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _mulbitint3_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o _divmodbitint4_s.o enable-execute-stack_s.o hardcfr_s.o strub_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so /home/share/gentoo/usr/libexec/gcc/s390x-ibm-linux-gnu/ld: /home/share/gentoo/usr/lib/../lib64/crti.o: Relocations in generic ELF (EM: 62) /home/share/gentoo/usr/libexec/gcc/s390x-ibm-linux-gnu/ld: /home/share/gentoo/usr/lib/../lib64/crti.o: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status No really sure what that tells me exactly, sorry. Is it trying to link object from different platforms (amd64 + s390x)? This used to work on the same system about half a year ago. Reproducible: Always
Created attachment 907565 [details] cross-s390x-ibm-linux-gnu-info.log
Created attachment 907566 [details] cross-s390x-ibm-linux-gnu-gcc-stage2.log.xz
Created attachment 907567 [details] gcc-config.logs.tar.xz
This looks odd and prefix specific somehow.
It works without prefix. I think this is an edge case I hadn't considered with my GCC ESYSROOT patch. The patch sets the sysroot based on ESYSROOT, but only for cross-compilers. In this case, a cross-compiler is being used, but ESYSROOT is set to the build host at /home/share/gentoo. Without prefix, ESYSROOT would be blank in this situation. I can't test it right now, but unsetting ESYSROOT during src_compile might fix it because gcc probably doesn't need additional help with the sysroot. I suspect we may need to do this for all the toolchain packages though, which isn't great. A more general solution would probably be to compare ESYSROOT with BROOT instead of merely checking whether it is non-empty.
(In reply to James Le Cuirot from comment #5) > I can't test it right now, but unsetting ESYSROOT during src_compile might > fix it because gcc probably doesn't need additional help with the sysroot. I > suspect we may need to do this for all the toolchain packages though, which > isn't great. Just to point this out, I can't test this either, because I don't know how. I know enough to make local changes to ebuild files, but I think this involves the toolchain class, and that is more than what I have experience with.
Okay, I'll get to it soon anyway. My desktop was just out of action for a while.
I've worked out a new patch. It's looking good, but it's a little more complicated now, so I'll give it some more testing first.
Can I help by testing something on my setup?
(In reply to Benjamin Block from comment #9) > Can I help by testing something on my setup? I don't think that's necessary, I've already tested this a fair bit. Other toolchain folks, please merge this.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=c088e880493faa16c2684fced43a2eb4cb67fe23 commit c088e880493faa16c2684fced43a2eb4cb67fe23 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2025-01-04 21:49:18 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-07 21:18:50 +0000 15.0.0: Update esysroot patch to fix prefix and Canadian Cross issues Closes: https://bugs.gentoo.org/942672 Signed-off-by: James Le Cuirot <chewi@gentoo.org> Closes: https://github.com/gentoo/gcc-patches/pull/7 Signed-off-by: Sam James <sam@gentoo.org> 15.0.0/gentoo/09_all_esysroot.patch | 77 ++++++++++++++++++++++++------------- 15.0.0/gentoo/README.history | 6 ++- 2 files changed, 56 insertions(+), 27 deletions(-) https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=7cf67113c79bdeac5e482e290adf47e473d92b8f commit 7cf67113c79bdeac5e482e290adf47e473d92b8f Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2025-01-04 21:47:17 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-07 21:18:17 +0000 14.2.0: Update esysroot patch to fix prefix and Canadian Cross issues Closes: https://bugs.gentoo.org/942672 Signed-off-by: James Le Cuirot <chewi@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> 14.2.0/gentoo/09_all_esysroot.patch | 75 ++++++++++++++++++++++++------------- 14.2.0/gentoo/README.history | 4 ++ 2 files changed, 54 insertions(+), 25 deletions(-)
Needs propagating into sys-devel/gcc revbumps next.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=01317a141265a7194933b4ddb0d6fe94d983431a commit 01317a141265a7194933b4ddb0d6fe94d983431a Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-09 03:43:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-09 03:43:41 +0000 sys-devel/gcc: add 14.2.1_p20250208 Bug: https://bugs.gentoo.org/942672 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/Manifest | 2 ++ sys-devel/gcc/gcc-14.2.1_p20250208.ebuild | 54 +++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=90d3cca0095f4a1240eefa8aa3fa8923f9e61680 commit 90d3cca0095f4a1240eefa8aa3fa8923f9e61680 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-10 00:00:03 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-10 00:00:03 +0000 sys-devel/gcc: add 15.0.1_pre20250209 Bug: https://bugs.gentoo.org/942672 Closes: https://bugs.gentoo.org/949124 Closes: https://bugs.gentoo.org/949388 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/Manifest | 2 ++ sys-devel/gcc/gcc-15.0.1_pre20250209.ebuild | 53 +++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+)
Since gcc-14.2.1_p20250301 is now at least unstable I got around to test whether this works again now, and yes it does. Successfully built a s390x-ibm-linux-gnu toolchain with crossdev-20250106.
Thanks, and I'm sorry for forgetting to update the bug!
