Created attachment 895698 [details] build.log and emerge --info Identical on both endians. $ grep -E "^FAIL: " /tmp/build.log FAIL: script_test_12 FAIL: ehdr_start_test_3 FAIL: DWARF parse during linker error FAIL: Build warn libbar.so FAIL: Run warn with versioned libfoo.so FAIL: --remap-inputs (simple) FAIL: --remap-inputs (wildcard) FAIL: --remap-inputs-file FAIL: --remap-inputs-file (with map output) FAIL: script_test_12 FAIL: ehdr_start_test_3 === ld Summary === # of expected passes 1816 # of unexpected failures 7 # of expected failures 8 # of untested testcases 1 # of unsupported tests 142 ./ld-new 2.42.0 make[6]: Entering directory '/var/tmp/portage/sys-devel/binutils-2.42-r1/work/build/gold/testsuite' /var/tmp/portage/sys-devel/binutils-2.42-r1/work/binutils-2.42/gold/../test-driver: line 107: 4682 Segmentation fault "$@" > $log_file 2>&1 FAIL: script_test_12 make[6]: Entering directory '/var/tmp/portage/sys-devel/binutils-2.42-r1/work/build/gold/testsuite' /var/tmp/portage/sys-devel/binutils-2.42-r1/work/binutils-2.42/gold/../test-driver: line 107: 5892 Segmentation fault "$@" > $log_file 2> &1 FAIL: ehdr_start_test_3
The gold failures are unimportant as gold is dead upstream and no bugs are being answered. For the other stuff, can you get ld.log please?
(In reply to Sam James from comment #1) > The gold failures are unimportant as gold is dead upstream and no bugs are > being answered. > > For the other stuff, can you get ld.log please? Should we mask it then? Or at least use.stable.mask?
(In reply to matoro from comment #2) > (In reply to Sam James from comment #1) > > The gold failures are unimportant as gold is dead upstream and no bugs are > > being answered. > > > > For the other stuff, can you get ld.log please? > > Should we mask it then? Or at least use.stable.mask? I think we can -- the only place we can't yet (IIRC) is arm64 because of stupid behaviour in dev-lang/go (upstream try to use gold in some cases).
(can+should)
Created attachment 895721 [details] build.log and emerge --info Better log with ld.log
Some of them look kind of like a race with the missing objects. Weird...
(In reply to Sam James from comment #6) > Some of them look kind of like a race with the missing objects. Weird... .. which also appears in bug 934149 at the end. Does it happen with -j1?
(In reply to Sam James from comment #7) > (In reply to Sam James from comment #6) > > Some of them look kind of like a race with the missing objects. Weird... > > .. which also appears in bug 934149 at the end. Does it happen with -j1? With -g, and -j1, the remaining fails are: FAIL: --remap-inputs (simple) FAIL: --remap-inputs (wildcard) FAIL: --remap-inputs-file FAIL: --remap-inputs-file (with map output)
-g fix: https://bugs.gentoo.org/934149#c11. --remap-inputs ended up being caused by our patch 'Gentoo: gold/ld: add support for poisoned system directories' which we're going to drop as it's not worth it. (Looks like it was the option_values hunk in ldlex.h but not worth spending more time on this, there's already better ways of achieving what that patch did by making ld error out on unrecognised object formats in library search paths like lld does.)
commit 2c932a9d704ff21cafe606bc09d254e3d48c551b Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Sat Jun 29 18:15:43 2024 +0200 sys-devel/binutils: bump 2.42-r2 to patchset 5, reverts some gentoo-specific stuff Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> It doesn't have the -g fix though.
