This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A glibc dynamic linker or gld bug?


   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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]