On Thu, Oct 28 2021, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
> On Thu, Oct 28 2021, Jonathan Gray <j...@jsg.id.au> wrote:
>> On Thu, Oct 28, 2021 at 10:30:36AM +0200, Christian Weisgerber wrote:
>>> Jonathan Gray:
>>>
>>> > > fvwm2 may be an exception here. I looked through the log and can't find
>>> > > any error before the linker error:
>>> > >
>>> > > ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to
>>> > > pthread_mutexattr_init [--no-allow-shlib-undefined]
>>> > > ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to
>>> > > pthread_mutexattr_settype [--no-allow-shlib-undefined]
>>> > > ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to
>>> > > pthread_mutexattr_destroy [--no-allow-shlib-undefined]
>>> > >
>>> > > Leads me to conclude that we need to add -lpthread now to satisfy
>>> > > clang13. Diff for that below; CC maintainer. ok?
>>> >
>>> > There are multiple ports which fail to build like this.
>>> >
>>> > Shouldn't libintl instead link libpthread?
>>>
>>> Shouldn't we try to understand why this is failing now?
>>
>> I suspect changes to undefined symbol handling in lld mentioned
>> in the lld 13 release notes:
>>
>> https://releases.llvm.org/13.0.0/tools/lld/docs/ReleaseNotes.html
>
> libintl uses weak symbols on purpose, the three symbols mentioned above
> are marked as such in libintl.so. See gettext-runtime/intl/lock.h for
> a rationale.
>
> Maybe I'm missing something but the libintl approach looks correct to
> me and the recent changes in lld land look incomplete/incorrect.
For the record the code in ld.lld(1) is:
--8<--
if (config->unresolvedSymbolsInShlib != UnresolvedPolicy::Ignore) {
auto diagnose =
config->unresolvedSymbolsInShlib == UnresolvedPolicy::ReportError
? errorOrWarn
: warn;
// Error on undefined symbols in a shared object, if all of its DT_NEEDED
// entries are seen. These cases would otherwise lead to runtime errors
// reported by the dynamic linker.
//
// ld.bfd traces all DT_NEEDED to emulate the logic of the dynamic linker to
// catch more cases. That is too much for us. Our approach resembles the one
// used in ld.gold, achieves a good balance to be useful but not too smart.
for (SharedFile *file : sharedFiles) {
bool allNeededIsKnown =
llvm::all_of(file->dtNeeded, [&](StringRef needed) {
return symtab->soNames.count(needed);
});
if (!allNeededIsKnown)
continue;
for (Symbol *sym : file->requiredSymbols)
if (sym->isUndefined() && !sym->isWeak())
diagnose(toString(file) + ": undefined reference to " +
toString(*sym) + " [--no-allow-shlib-undefined]");
}
}
-->8--
So apparently pthread_mutexattr_init and friends aren't "weak" in this
context, even though they are in libintl.so.
Looking closer:
--8<--
russell
/usr/ports/pobj/pinentry-1.1.1-no_gtk2-no_gnome3-bootstrap/pinentry-1.1.1/curses$
doas -u _pbuild cc -Wl,--trace-symbol,pthread_mutexattr_init -v -O2 -pipe
-Wall -Wno-pointer-sign -Wpointer-arith -L/usr/local/lib -o pinentry-curses
pinentry-curses.o ../pinentry/libpinentry.a ../pinentry/libpinentry-curses.>
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.0
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker
/usr/libexec/ld.so -o pinentry-curses /usr/lib/crt0.o /usr/lib/crtbegin.o
-L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/lib
--trace-symbol pthread_mutexattr_init pinentry-curses.o
../pinentry/libpinentry.a ../pinentry/libpinentry-curses.a
../secmem/libsecmem.a -lsecret-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl
-lassuan -lgpg-error -lncursesw /usr/local/lib/libiconv.so.7.0 -lcompiler_rt
-lc -lcompiler_rt /usr/lib/crtend.o
/usr/local/lib/libglib-2.0.so.4201.7: reference to pthread_mutexattr_init
/usr/local/lib/libintl.so.7.0: reference to pthread_mutexattr_init
ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to
pthread_mutexattr_destroy [--no-allow-shlib-undefined]
ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to
pthread_mutexattr_init [--no-allow-shlib-undefined]
ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to
pthread_mutexattr_settype [--no-allow-shlib-undefined]
cc: error: linker command failed with exit code 1 (use -v to see invocation)
-->8--
libglib-2.0.so is before libintl on the command-line, its global +
undefined reference to pthread_mutexattr_init seems to be cached and
preferred over the weak + undefined reference in libintl.so.
If I move -lintl before -lglib-2.0 on the command line, the error
doesn't trigger:
--8<--
ntry-curses pinentry-curses.o ../pinentry/libpinentry.a
../pinentry/libpinentry-curses.a ../secmem/libsecmem.a -L/usr/local/lib -lintl
-lsecret-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -L/usr/local/lib -lassuan
-L/usr/local/lib -lgpg-error -lncursesw /usr/local/lib/libiconv.so.7.0
<
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.0
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker
/usr/libexec/ld.so -o pinentry-curses /usr/lib/crt0.o /usr/lib/crtbegin.o
-L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/lib
--trace-symbol pthread_mutexattr_init pinentry-curses.o
../pinentry/libpinentry.a ../pinentry/libpinentry-curses.a
../secmem/libsecmem.a -lintl -lsecret-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0
-lassuan -lgpg-error -lncursesw /usr/local/lib/libiconv.so.7.0 -lcompiler_rt
-lc -lcompiler_rt /usr/lib/crtend.o
/usr/local/lib/libintl.so.7.0: reference to pthread_mutexattr_init
/usr/local/lib/libglib-2.0.so.4201.7: reference to pthread_mutexattr_init
-->8--
The comment in Writer.cpp says
// Error on undefined symbols in a shared object, if all of its DT_NEEDED
// entries are seen. These cases would otherwise lead to runtime errors
// reported by the dynamic linker.
//
// ld.bfd traces all DT_NEEDED to emulate the logic of the dynamic linker to
// catch more cases. That is too much for us. Our approach resembles the one
// used in ld.gold, achieves a good balance to be useful but not too smart.
Looks like lld isn't smart enough to be useful in that situation.
Maybe we should disable this check for now? Or does someone feels like
fixing it?
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
