This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: A glibc dynamic linker or gld bug?
- To: hjl@lucon.org
- Subject: Re: A glibc dynamic linker or gld bug?
- From: Ian Lance Taylor <ian@zembu.com>
- Date: 7 Jul 1999 10:43:18 -0400
- CC: hjl@lucon.org, rth@twiddle.net, geoffk@ozemail.com.au, drepper@cygnus.com, binutils@sourceware.cygnus.com, jgg@ualberta.ca
- References: <19990707143901.2022657BA@ocean.lucon.org>
Date: Wed, 7 Jul 1999 07:39:01 -0700 (PDT)
From: hjl@lucon.org (H.J. Lu)
> > As far as I can see, this can only happen if all relocations involving
> > the weak defined symbol are copied into the executable as dynamic
> > relocations.
>
> What if the definition in executable is strong? Do you have the same
> problem? I don't think we should worry about this.
>
> No, we don't have the same problem if the definition in the executable
> is strong, because in that case the shared library will never override
> the definition. The only time a shared library can override a
> definition is if it is weak in the executable.
By "problem", I mean the same symbol will have different values in
executable and DSO. When you update one of them, you won't see the
change in the other. If you relink executable against the new DSO,
the symbol in executable will override the one in DSO.
I guess I don't understand. The DSO should have relocations for all
uses of the symbol, so it will wind up seeing the definition in the
executable. At runtime the symbol will not have different values.
This is an ordinary case in which the executable overrides the DSO.
As far as I know, the only way you can get a DSO to see a different
value from the main executable is to use -Bsymbolic or version
scripts. Also, you have just reported a case in which it happens due
to the use of weak defined symbols in the executable. But there
definitely should not be any way to make the DSO and the executable
see a different value for a strong defined symbol.
Ian