On Nov 8, 2021, at 6:41 PM, Kurt Miller <[email protected]> wrote: > > On Nov 8, 2021, at 4:48 PM, Christian Weisgerber <[email protected]> wrote: >> >> Jeremie Courreges-Anglas: >> >>> Those are two approaches to get past this failure, but I suspect that >>> the root cause is just a bug / limitation introduced in this llvm >>> release. The approach taken by libintl looks reasonable to me, >> >> I'm looking at security/pinentry as an example case, and it's a >> headscratcher. >> >> libglib-2.0.so is loaded first, and it has undefined references to >> pthread_mutexattr_*() as well as a DT_NEEDED for libpthread.so. >> libintl.so with its weak references to pthread_mutexattr_*() comes >> later. How can pthread_mutexattr_*() end up as undefined there? > > jca@ original analysis points to ld.lld not being smart enough > to deal with that case. That appears to be the case and it really > should be treated as a weak symbol, not an undefined symbol > for libintl. > >> IIRC, the last lld update saw a change where libxxx with DT_NEEDED >> for Libby now meant that only libxxx would see the symbols from >> libyyy. If other object files reference symbols from libyyy, an >> explicit -lyyy is needed. So that would explain why libintl doesn't >> see the libpthread that is pulled in by libglib. But in that case >> libintl should fall back to the weak symbol reference. > > I checked our runtime linker and libintl’s weak symbols for > pthread_mutexattr_* are resolved at runtime by the libpthread > that is linked in indirectly via glib. Since that is the case we might > as well link the affected ports (not libintl.so, the ports with linking > errors) with -pthread since they already link indirectly to pthreads. > > I think disabling --no-allow-shlib-undefined is probably not justified > given the small number of ports effected so far. >
Or maybe cleaner would be to just disable the buggy ld.lld check on the ports that fail to link by adding -Wl,--allow-shlib-undefined to LDFLAGS. -Kurt
