This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: [new test case jluu@mainsoft.com: Re: Possible linker problem]
On Tue, Mar 14, 2000 at 12:58:37PM -0800, Ian Lance Taylor wrote:
> 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.
The native Solaris linker on Sparc behaves the same as the GNU ld.
H.J.