Re: [new test case jluu@mainsoft.com: Re: Possible linker problem]

[Ian Lance Taylor <ian at zembu dot com>]

   From: "Jose Luu" <jluu@mainsoft.com>
   Date: Tue, 14 Mar 2000 19:40:44 +0100

   In the case I am reporting, C++ is not involved (finally, after more work on
   pinning it down).

   The executable is referencing a symbol in the shared library with no intent
   to override (declared as external int).

   The shared library is linked with Bsymbolic.

   The result is that the said symbol also becomes defined in the executable,
   so we have 2 symbols with the same name and the confusion that results.

Thanks for the test case.  This is an interesting problem.

The library is defining a variable, val_in_shared.  When a shared
library defines a variable, and the main program refers to it, the
main program allocates space for the variable in its own BSS segment,
and uses a COPY relocation to initialize it.  This new variable then
effectively overrides the version in the shared library.  Since when
the shared library was created all references to the variable either
used the GOT or had dynamic relocs, the shared library will
automatically refer to the copied version of the variable.

However, when the library is linked with -Bsymbolic, then the linker
does not create the dynamic relocs required to permit the variable to
be overridden from the main program.  Therefore, allocating the
variable in a private BSS segment and using a COPY reloc will not
work.

Could somebody please try this test case on Solaris, using the native
Solaris linker?  I would like to see what that linker will do.

Offhand, one way to make this work would be to check whether a symbol
was defined in a -Bsymbolic shared library before creating a COPY
reloc.  In that particular case, we could not generate a COPY reloc,
but would instead create dynamic relocations for all the references to
that symbol in the main program.  But that would be a real pain.

Another way to make it work would be to generate the dynamic
relocations for a variable when creating a -Bsymbolic shared library.
But the only reason to use -Bsymbolic is for efficiency, and that
would always lose efficiency in order to solve a problem which rarely
occurs.

Ian