https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #9 from Nick Alcock <nick.alcock at oracle dot com> --- OK, so this GCC was configured with --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as These absolute paths force collect2 to use those paths no matter what -B says. nix@s11-sparc:~/binutils-gdb/build/libctf$ gcc -v -B/home/nix/binutils-gdb/build/libctf/tmpdir/libctf/ -print-prog-name=collect-ld Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/gcc/14/lib/gcc/sparcv9-sun-solaris2.11/14.2.0/lto-wrapper /home/nix/binutils-gdb/build/libctf/tmpdir/libctf/collect-ld nix@s11-sparc:~/binutils-gdb/build/libctf$ gcc -v -B/home/nix/binutils-gdb/build/libctf/tmpdir/libctf/ -print-prog-name=ld Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/gcc/14/lib/gcc/sparcv9-sun-solaris2.11/14.2.0/lto-wrapper /usr/bin/ld (even though both tools have symlinks in libctf/tmpdir/libctf.) The annoying thing is, this exact problem is what the "collect-ld" symlink is supposed to fix, back in the day... but the copy of find_a_file() used by collect2 has a special exception for absolute paths :( -- You are receiving this mail because: You are on the CC list for the bug.
