https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82575
--- Comment #5 from Alan Modra <amodra at gmail dot com> --- > --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- > Hmm, but those symbols will prevail, enlarging the final symbol table? > Or are weak + hidden symbols removed even for shared libaries? Well, they are still undefined. Being hidden they won't become dynamic unless your linker is broken. > IIRC the Solaris linker didn't like to interpret "unused" (aka unreferenced) From pr81968 it seems the symbol related complaint was just that the linker warned on seeing a global symbol without name, which is kind of reasonable given that a global symbol's linkage is via name. > UNDEF globals as irrelevant, complaining about missing symbols later. GNU > ld simply discards those in the partial link we perform over all debug > objects. Yes, it's possible that other linkers might not remove the undefined symbols from .symtab, which would leave nm and other binutils broken. If that happens, I suppose we could edit .strtab to change the name of __gnu_lto_slim, or bump st_name by one. Changing global syms to local doesn't work since the locals must be first in .symtab. Using STT_FILE would work with GNU ld, but it's anybody's guess how global STT_FILE symbols are handled in other linkers.
