https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: app-admin/authbind-2.1.2 fails to compile with clang/lld. Discovered on: amd64 (internal ref: tinderbox) NOTE: This machine uses clang as a compiler and lld as a linker.
Created attachment 758311 [details] build.log build log and emerge --info
Error(s) that match a know pattern: ld.lld: error: unable to find library -ldl
I think this is caused by setting LD which we consider to be unsupported. You should just set -fuse-ld instead.
(In reply to Sam James from comment #3) > I think this is caused by setting LD which we consider to be unsupported. > You should just set -fuse-ld instead. This is what was done, unless I misunderstood what are you saying: x86_64-pc-linux-gnu-clang -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -fuse-ld=lld authbind.o -o authbind
(In reply to Agostino Sarubbo from comment #4) > (In reply to Sam James from comment #3) > > I think this is caused by setting LD which we consider to be unsupported. > > You should just set -fuse-ld instead. > > This is what was done, unless I misunderstood what are you saying: > > x86_64-pc-linux-gnu-clang -Wl,-O1 -Wl,--as-needed > -Wl,--defsym=__gentoo_check_ldflags__=0 -fuse-ld=lld authbind.o -o > authbind So, it works for me if I *just* do *FLAGS="... -fuse-ld=lld", but if I set LD=ld.lld, it fails like in this bug. Setting LD (and calling LD directly in the build system) is considered obsolete and most things don't support it. It's because calling LD is inflexible and doesn't allow passing options correctly. So, I would not bother setting LD=... in the tinderbox. Only -fuse-ld=foo.
(In reply to Sam James from comment #5) > (In reply to Agostino Sarubbo from comment #4) > > (In reply to Sam James from comment #3) > > > I think this is caused by setting LD which we consider to be unsupported. > > > You should just set -fuse-ld instead. > > > > This is what was done, unless I misunderstood what are you saying: > > > > x86_64-pc-linux-gnu-clang -Wl,-O1 -Wl,--as-needed > > -Wl,--defsym=__gentoo_check_ldflags__=0 -fuse-ld=lld authbind.o -o > > authbind > > So, it works for me if I *just* do *FLAGS="... -fuse-ld=lld", but if I set > LD=ld.lld, it fails like in this bug. Right, but I guess this is a case where it uses $LD instead of $CC/CXX for link
(In reply to Agostino Sarubbo from comment #6) > (In reply to Sam James from comment #5) > > (In reply to Agostino Sarubbo from comment #4) > > > (In reply to Sam James from comment #3) > > > > I think this is caused by setting LD which we consider to be unsupported. > > > > You should just set -fuse-ld instead. > > > > > > This is what was done, unless I misunderstood what are you saying: > > > > > > x86_64-pc-linux-gnu-clang -Wl,-O1 -Wl,--as-needed > > > -Wl,--defsym=__gentoo_check_ldflags__=0 -fuse-ld=lld authbind.o -o > > > authbind > > > > So, it works for me if I *just* do *FLAGS="... -fuse-ld=lld", but if I set > > LD=ld.lld, it fails like in this bug. > > Right, but I guess this is a case where it uses $LD instead of $CC/CXX for > link Ah! I was about to write "I think it uses LD if it's set, but if it's not, it'll do the right thing" (this has happened lots before), but you're right! But there's some bad news too: ld.lld: error: duplicate symbol: _init >>> defined at /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../lib64/crti.o:(.init+0x0) >>> defined at libauthbind.c:116 (/var/tmp/portage/app-admin/authbind-2.1.2/work/authbind/libauthbind.c:116) >>> libauthbind.o:(.text+0x340) collect2: error: ld returned 1 exit status It's doing something quite naughty :(
Created attachment 785003 [details, diff] 0001-app-admin-authbind-don-t-call-LD-directly.patch I'm not sure if the attached patch is right or not. The behaviour differs when invoked as ld vs via the gcc driver. I tried to see the relevant options but didn't figure it out. I'm not sure how to test the authbind library either. Hm.
