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. -Kurt
