[Bug 285401] x11/libxkbcommon: after recent updates to 1.8.0 and 1.8.1 several ports may need a PORTREVISION bump
Date: Sun, 23 Mar 2025 03:44:48 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285401
--- Comment #68 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to Dimitry Andric from comment #62)
(In reply to Baptiste Daroussin from comment #59)
I have identified the code in lld/ELF/Writer.cpp 's
Writer<ELFT>::finalizeSections() that avoids reporting
a "diagnose" for the likes of environ and __progname
issue in main [so: 15+].
In the later, larger quote of text it is the part:
for (SharedFile *file : ctx.sharedFiles) {
bool allNeededIsKnown =
llvm::all_of(file->dtNeeded, [&](StringRef needed) {
return symtab.soNames.count(CachedHashStringRef(needed));
});
if (!allNeededIsKnown)
continue;
. . . (dispose activity for file goes here, for example) . . .
Basically it avoids doing "diagnose" activity based
on the incomplete information if something like:
0x0000000000000001 NEEDED Shared library: [libsys.so.7]
has not been processed that could contribute for
file. (From it's view of view the missing material
could be what supplies what would end up doing a
diagnose on, thus producing potential false positives.)
So it looks like getting the diagnose output for 15+
of FreeBSD would mean this is the area that would
need to have FreeBSD specific code dealing with the
libc.so.* needing its matching libsys.so.* but just
the libsys.so.* being missing for the libc.so.* :
still diagnose such a file context.
I'll note that on 15+ libc.so.7 actually has 5 undefined
GLOBALs, instead of 2, although the other 3 have:
"@FBSDprivate_1.0 (12)" as well:
2: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND environ
3: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __progname
4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND
_elf_aux_info@FBSDprivate_1.0 (12)
5: 0000000000000000 0 OBJECT GLOBAL DEFAULT UND
__elf_aux_vector@FBSDprivate_1.0 (12)
6: 0000000000000000 0 FUNC GLOBAL DEFAULT UND
__libsys_interposing_slot@FBSDprivate_1.0 (12)
For reference, the larger quote of code for this is:
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.
//
// If a DSO reference is resolved by a SharedSymbol, but the SharedSymbol
// is overridden by a hidden visibility Defined (which is later discarded
// due to GC), don't report the diagnostic. However, this may indicate an
// unintended SharedSymbol.
for (SharedFile *file : ctx.sharedFiles) {
bool allNeededIsKnown =
llvm::all_of(file->dtNeeded, [&](StringRef needed) {
return symtab.soNames.count(CachedHashStringRef(needed));
});
if (!allNeededIsKnown)
continue;
for (Symbol *sym : file->requiredSymbols) {
if (sym->dsoDefined)
continue;
if (sym->isUndefined() && !sym->isWeak()) {
diagnose("undefined reference: " + toString(*sym) +
"\n>>> referenced by " + toString(file) +
" (disallowed by --no-allow-shlib-undefined)");
} else if (sym->isDefined() && sym->computeBinding() == STB_LOCAL) {
diagnose("non-exported symbol '" + toString(*sym) + "' in '" +
toString(sym->file) + "' is referenced by DSO '" +
toString(file) + "'");
}
}
}
}
--
You are receiving this mail because:
You are on the CC list for the bug.