It happens quite frequently that people report bugs that cannot be reproduced by any1 until someone finds out that he was/is using ld.gold. ld.gold has different behavior for as-needed, does not permit underlinking, is known to cause problems on some packages and so forth, so having that information in "emerge --info" would really make life easier example bug 435826
Should we parse the output of `ld --version` or what?
`${CHOST}-ld --version | head -1` and `${CC:-${CHOST}-gcc} --version | head -1`
(In reply to comment #2) > `${CHOST}-ld --version | head -1` and `${CC:-${CHOST}-gcc} --version | head > -1` can we make that `${CHOST}-ld -v |& head -n1`? % ld --version | head -1 ld: unknown option: --version % ld -v |& head -n1 @(#)PROGRAM:ld PROJECT:ld64-128.2 (Gentoo binutils-apple-4.3)
using --version rather than -v for both is fine. if the selected tool doesn't support --version, then screw em.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4126fcfb04efcedaf857b0f6977effb82c24e1cb
can we use the output of gcc --print-prog-name=ld and fall back to ${CHOST}-ld if that doesn't return anything?
s/gcc/$CC/ or how else we correctly find the compiler in use
(In reply to comment #5) > This is fixed in git: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=4126fcfb04efcedaf857b0f6977effb82c24e1cb This is in portage 2.1.11.31 and 2.2.0_alpha142. (In reply to comment #7) > s/gcc/$CC/ or how else we correctly find the compiler in use I'll wait and see what toolchain people say.
(In reply to comment #6) that won't work if $LD is set i think
can we close this?
