https://sourceware.org/bugzilla/show_bug.cgi?id=33177
--- Comment #4 from Alan Modra <amodra at gmail dot com> --- (In reply to Rainer Orth from comment #3) > The attached example shows what's going on: > > * I created shared objects with gcc configured to use gas/ld (libld.so) and > gas/gld (libgld.so). This contains a _GLOBAL_OFFSET_TABLE_ definition > since that's one of the Solaris ABI symbols. When linked with ld, the > symbol > is global with protected visibility, with gld it's global with default > visibility. Where in the solaris ABI does it say _GLOBAL_OFFSET_TABLE_ must be dynamic? It is interesting that it is made protected by solaris ld, which is acknowledging that the symbol is only useful in the shared library when resolving references to the shared library GOT. ie. a reference in the shared library should *not* resolve to the executable _G_O_T_. It should at least be made protected by gld too. > * When linking an executable against either lib with > --as-needed/--no-as-needed, > gld drags in the library because of these _G_O_T_ definitions, while ld > does > not. > > * The _G_O_T_ reference that triggers this is from one of the Solaris CRTs: > crtbegin.o on x86, crt1.o in sparc, as can be seen when running gld with > -M. Right, the reference is from a non-weak undefined symbol in a regular object file, so is satisfied by the dynamic definition in the library. > * From what I learned from Ali (and can also be seen when running ld with > LD_DEBUG=all,detail), ld creates the ABI-specified symbols (_G_O_T_ > included) > very early on, so the references from the CRTs can be resolved from that. In gld the symbols are not created early. _GLOBAL_OFFSET_TABLE_ is defined in elflink.c:_bfd_elf_create_got_section, which is called via bfd_elf_link_create_dynamic_sections *after* the first dynamic library is determined to be needed to sasify symbol refs. > I've so far struggled in vain how to handle this. I think it might be > possible > (at least as a workaround) with --defsym or a linker script, but so far have > failed. -- You are receiving this mail because: You are on the CC list for the bug.
