Created attachment 919074 [details] sys-devel:binutils-2.43-r2:20250216-092105.log While rebuilding in an emptytree rebuild on a fairly-new system, =sys-devel/binutils-2.43-r2 fails its test phase for me, specifically: Running /var/tmp/portage/sys-devel/binutils-2.43-r2/work/binutils-2.43/ld/testsuite/ld-elf/compress.exp ... FAIL: Link with zlib-gabi compressed debug input When I searched the Web for that failure, there were only three results, namely two in build logs checked into a "riscv-gnu-toolchain" repository in 2017 and one in https://sourceware.org/bugzilla/show_bug.cgi?id=21665 (also from 2017) --- all amid several other failures that I don't see. So I have no idea how serious this is.
Created attachment 919075 [details] emerge-info.txt
Could you grab /var/tmp/portage/sys-devel/binutils-2.43-r2/work/build/ld/ld.log for me?
Created attachment 919076 [details] ld.log.gz
``` PASS: Run gabinormal with libgabifoo.so with zlib-gabi compressed debug sections x86_64-pc-linux-gnu-gcc -B/var/tmp/portage/sys-devel/binutils-2.43-r2/work/build/ld/tmpdir/ld/ -I/var/tmp/portage/sys-devel/binutils-2.43-r2/work/binutils-2.43/ld/testsuite/ld-elf -O2 -pipe -march=core2 -mtune=native -std=gnu17 -fno-sanitize=all -c -fno-lto -Wa,--compress-debug-sections=zlib-gabi -c /var/tmp/portage/sys-devel/binutils-2.43-r2/work/binutils-2.43/ld/testsuite/ld-elf/main.c -o tmpdir/main.o Executing on host: sh -c {x86_64-pc-linux-gnu-gcc -B/var/tmp/portage/sys-devel/binutils-2.43-r2/work/build/ld/tmpdir/ld/ -I/var/tmp/portage/sys-devel/binutils-2.43-r2/work/binutils-2.43/ld/testsuite/ld-elf -O2 -pipe -march=core2 -mtune=native -std=gnu17 -fno-sanitize=all -c -fno-lto -Wa,--compress-debug-sections=zlib-gabi -c /var/tmp/portage/sys-devel/binutils-2.43-r2/work/binutils-2.43/ld/testsuite/ld-elf/main.c -o tmpdir/main.o 2>&1} /dev/null ld.tmp (timeout = 300) spawn [open ...] x86_64-pc-linux-gnu-gcc -B/var/tmp/portage/sys-devel/binutils-2.43-r2/work/build/ld/tmpdir/ld/ -L/usr/x86_64-pc-linux-gnu/lib64 -L/usr/lib64/binutils/x86_64-pc-linux-gnu/2.4364 -L/usr/local/lib64 -L/lib64 -L/usr/lib64 -L/usr/x86_64-pc-linux-gnu/lib -L/usr/lib64/binutils/x86_64-pc-linux-gnu/2.43 -L/usr/local/lib -L/lib -L/usr/lib -o tmpdir/gabinormal -L/var/tmp/portage/sys-devel/binutils-2.43-r2/work/binutils-2.43/ld/testsuite/ld-elf tmpdir/zlibbegin.o tmpdir/libfoozlib.so tmpdir/gabiend.o -Wl,--compress-debug-sections=zlib-gabi tmpdir/main.o Executing on host: sh -c {x86_64-pc-linux-gnu-gcc -B/var/tmp/portage/sys-devel/binutils-2.43-r2/work/build/ld/tmpdir/ld/ -L/usr/x86_64-pc-linux-gnu/lib64 -L/usr/lib64/binutils/x86_64-pc-linux-gnu/2.4364 -L/usr/local/lib64 -L/lib64 -L/usr/lib64 -L/usr/x86_64-pc-linux-gnu/lib -L/usr/lib64/binutils/x86_64-pc-linux-gnu/2.43 -L/usr/local/lib -L/lib -L/usr/lib -o tmpdir/gabinormal -L/var/tmp/portage/sys-devel/binutils-2.43-r2/work/binutils-2.43/ld/testsuite/ld-elf tmpdir/zlibbegin.o tmpdir/libfoozlib.so tmpdir/gabiend.o -Wl,--compress-debug-sections=zlib-gabi tmpdir/main.o 2>&1} /dev/null ld.tmp (timeout = 300) spawn [open ...] Running: tmpdir/gabinormal > tmpdir/gabinormal.out TEST1 TEST1 MAIN PASS: Run gabinormal with libfoozlib.so with zlib-gabi compressed debug sections cmp tmpdir/libfoo.so tmpdir/libfoozlib.so tmpdir/libfoo.so tmpdir/libfoozlib.so differ. FAIL: Link with zlib-gabi compressed debug input ``` You can try manually run the commands from the log to recreate libfoo.so and libfoozlib.so and then upload them here -- but first, try without distcc?
While trying to figure out how to recreate libfoo.so and libfoozlib.so I've only gotten myself confused, but in rebuilding and rerunning the test suite (both manually and via 'emerge', all with distcc turned off and MAKEOPTS=-j1) I've seen both successful all-tests-pass runs, runs with just this failure, and runs with this and also "FAIL: Link with zlib-gabi compressed debug output 1".
The purpose of the test is to make sure that a 'round-trip' can be done without corrupting the compressed section (... of debug information), so it takes some libfoo, builds it, then compresses it, decompresses it, and makes sure it gets the same result. The fact it's flaky is a bit odd -- I was going to say it may be a parallelism thing, but -j1 rather defeats that theory. Unfortunately, I think the binutils testsuite reuses a bunch of test filenames, which is why I was asking you to try reproduce it manually. That's still possible by running commands (which I can try dig up, the dejagnu log isn't friendly to parse), but I may be able to give you a patch to disable the other tests -- not sure what's easier yet. I need to get back to you.
