So I removed `binutils` from my implicit system set and tried to build a full system. Things failed in an unexpected way. In ChromeOS, we by default block specific build tools ($ABI-{ar,gcc,ld,etc}) by [generating a wrapper](https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/profiles/base/profile.bashrc#411) script that raises an error and kills the ebuild processes. This is useful to tracking down instances of packages that aren't respecting their $CC, $LD, etc variables. It turns out that there are a some (not sure how many) autoconf packages that include the following code in their ./configure: ``` # ancient GNU ld didn't support --whole-archive et. al. if eval "`$CC -print-prog-name=ld` --help 2>&1" | $GREP 'no-whole-archive' > /dev/null; then whole_archive_flag_spec_CXX=$wlarc'--whole-archive$convenience '$wlarc'--no-whole-archive' else whole_archive_flag_spec_CXX= fi ``` This results in the following failure: ``` checking if the linker (x86_64-pc-linux-gnu-ld.lld -m elf_x86_64) is GNU ld... yes * x86_64-pc-linux-gnu-ld: ERROR: Unexpected use of GCC/GNU Binutils. * x86_64-pc-linux-gnu-ld: ERROR: If this use is necessary, please call cros_allow_gnu_build_tools in the ebuild ``` When `binutils` is installed and `x86_64-pc-linux-gnu-ld` exists, `-print-prog-name` uses its own PATH priority list to find the prog: ``` PATH="/var/tmp/portage/sys-devel/libtool-2.4.6-r7/temp/build-toolchain-wrappers/gnu_tools:$PATH" x86_64-pc-linux-gnu-clang++ -print-prog-name=ld /usr/bin/x86_64-pc-linux-gnu-ld ``` When `binutils` isn't installed and `x86_64-pc-linux-gnu-ld` is missing, -print-prog-name` will return the wrapper. ``` $ PATH="/var/tmp/portage/sys-devel/libtool-2.4.6-r7/temp/build-toolchain-wrappers/gnu_tools:$PATH" x86_64-pc-linux-gnu-clang++ -print-prog-name=ld /var/tmp/portage/sys-devel/libtool-2.4.6-r7/temp/build-toolchain-wrappers/gnu_tools/x86_64-pc-linux-gnu-ld ``` So when `print-prog-name=ld` is used, it is circumventing our wrapper. This was an unexpected find. One potential solution is to not generate the wrapper script for binaries that don't exist. This has the down side that the bash code posted above will try and invoke `x86_64-pc-linux-gnu-ld` which doesn't exist, and it will raise a `QA notice` saying that a command was executed that wasn't found. This will then fail the build :/ I think the correct fix is to fix the code so that it uses the `$LD` variable instead of `-print-prog-name`. I don't really know what the best course of action is. Is this something that should be fixed in autoconf and then the packages need to regen their ./configure script, or do we just patch the offending packages? Here is the current list, I'm sure there are more: * sys-devel/libtool:2.4.6-r7 * dev-util/re2c:2.2-r1 * sys-devel/gettext:0.21-r3 * net-dns/c-ares:1.19.1 * sys-devel/flex:2.6.4-r2 * dev-libs/libusb:1.0.26-r1
FWIW, an autoconf release is imminent next week, so if you can reproduce this with a vanilla configure.ac w/ latest ac, please do report it as a bug there upstream ASAP (now!).
Thanks for that info. I can try to repro tomorrow.
Ah, so I think it's coming from the libtool macro: ``` rrangel920 /var/tmp/portage/dev-util/re2c-2.2-r1/work/re2c-2.2 # grep -A5 -B 2 -R "ancient GNU ld" ./m4/libtool.m4 _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath $wl$libdir' _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl--export-dynamic' # ancient GNU ld didn't support --whole-archive et. al. if $LD --help 2>&1 | $GREP 'no-whole-archive' > /dev/null; then _LT_TAGVAR(whole_archive_flag_spec, $1)=$wlarc'--whole-archive$convenience '$wlarc'--no-whole-archive' else _LT_TAGVAR(whole_archive_flag_spec, $1)= fi -- wlarc='$wl' # ancient GNU ld didn't support --whole-archive et. al. if eval "`$CC -print-prog-name=ld` --help 2>&1" | $GREP 'no-whole-archive' > /dev/null; then _LT_TAGVAR(whole_archive_flag_spec, $1)=$wlarc'--whole-archive$convenience '$wlarc'--no-whole-archive' else _LT_TAGVAR(whole_archive_flag_spec, $1)= ```
Pushed a patch to libtool upstream: https://savannah.gnu.org/support/index.php?110978
i merged it upstream. let's see if we can get a libtool 2.4.8 this month w/it.
(In reply to SpanKY from comment #5) > i merged it upstream. let's see if we can get a libtool 2.4.8 this month > w/it. Nice to see upstream alive again, will you merge more old patches like the ones in eltpatches/debian/openembedded etc.?
(In reply to Joakim Tjernlund from comment #6) If you check the repo and mailing list, you'd see that's already being done (thanks mike)
