https://sourceware.org/bugzilla/show_bug.cgi?id=25236
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gmail dot com
--- Comment #2 from Alan Modra <amodra at gmail dot com> ---
Let's ignore symbol versioning for now. What is the correct result when
linking ld -shared -o a.so a.o b.so? In b.so we have a STB_GLOBAL STT_OBJECT
mpi_fortran_argvs_null_ defined in .bss, treated by ld as a common symbol. In
a.o we have a STB_GLOBAL STT_OBJECT mpi_fortran_argvs_null_ SHN_COMMON symbol.
The ELF spec says of STT_COMMON symbols: "When the dynamic linker encounters a
reference to a symbol that resolves to a definition of type STT_COMMON, it may
(but is not required to) change its symbol resolution rules as follows: instead
of binding the reference to the first symbol found with the given name, the
dynamic linker searches for the first symbol with that name with type other
than STT_COMMON. If no such symbol is found, it looks for the STT_COMMON
definition of that name that has the largest size."
OK, so we don't have STT_COMMON here (ld.bfd was implemented before STT_COMMON
was added to the ELF spec), but the behaviour of common symbols is clear. If
at runtime the dynamic linker may choose the common symbol with the largest
size, then it's quite correct for ld to do so too. This is old established
behaviour, dating back to at least 1997. I believe it is a bug that lld and
gold do not do this.
I haven't yet looked at why ld.bfd makes mpi_fortran_argvs_null_ versioned
local, that does seem odd.
--
You are receiving this mail because:
You are on the CC list for the bug.
