|Summary:||toolchain-funcs: gen_usr_ldscript doesn't write OUTPUT_FORMAT when using ld.gold|
|Product:||Gentoo Linux||Reporter:||Michał Górny <mgorny>|
|Component:||Eclasses||Assignee:||Gentoo Toolchain Maintainers <toolchain>|
|Severity:||normal||CC:||devurandom, esigra, nikoli, pacho, sam|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
|Bug Blocks:||269315, 487138|
Description Michał Górny 2013-10-11 20:33:18 UTC
When ld.gold is used as the linker, -Wl,--verbose doesn't output the OUTPUT_FORMAT line. As a result, gen_usr_ldscript doesn't write that in the linker script and the scripts confuse the linker w/ multilib.
Comment 1 SpanKY 2013-10-12 19:53:31 UTC
i don't think there's a way to tease out the info from gold. i'm also not sure how much effort we want to expend on this when bug 479448 is coming.
Comment 2 Michał Górny 2013-10-12 20:31:01 UTC
(In reply to SpanKY from comment #1) > i don't think there's a way to tease out the info from gold. i'm also not > sure how much effort we want to expend on this when bug 479448 is coming. It will still affect the packages afte 479448 is fixed. The underlying issue was that 'gcc -m32' found /usr/lib64/libfoo.la with no OUTPUT_FORMAT and assumed it is fine. By the way, I think this function should actually read the output format from the library being wrapped rather than an unrelated linker invocation.
Comment 3 SpanKY 2013-10-12 21:32:17 UTC
(In reply to Michał Górny from comment #2) i think the underlying issue there is that people are using bad -L flags. i added this hack way back when really only to mitigate things (and clearly it's been working, but maybe too well). reading the output format from the wrapped lib does make a lot of sense. i'd have to play around with binutils though to see if they support such a thing. i remembered that glibc has similar code to auto use ld.bfd when gold is active, so i just cribbed that logic: http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.122&r2=1.123 i'll leave this open though as a reminder to investigate the lib probing angle.
Comment 4 Larry the Git Cow 2022-12-06 05:45:10 UTC
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=88607de9c44a1b11017ecb7d2d5e8868c48b1695 commit 88607de9c44a1b11017ecb7d2d5e8868c48b1695 Author: Sam James <firstname.lastname@example.org> AuthorDate: 2022-12-06 05:44:03 +0000 Commit: Sam James <email@example.com> CommitDate: 2022-12-06 05:44:03 +0000 toolchain-funcs.eclass: stop using which(1) It's non-portable and we're looking to remove it from @system. Bug: https://bugs.gentoo.org/487696 Bug: https://bugs.gentoo.org/646588 Signed-off-by: Sam James <firstname.lastname@example.org> eclass/toolchain-funcs.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)