Re: global vars and symbol visibility for mips32/elf

[Ian Lance Taylor <ian@cygnus.com>]

   Date: Fri, 09 Aug 1996 13:13:00 -0700
   From: Ulrich Drepper <drepper@cygnus.com>

   From: Ian Lance Taylor <ian@cygnus.com>
   Subject: Re: global vars and symbol visibility for mips32/elf
   Date: Fri, 9 Aug 1996 11:29:54 -0400

   >    The problem is caused by the symbol 'glob'.  GNU libc also has a
   >    symbol glob.
   > 
   > This is the bug.  An ANSI C compliant shared library may not have a
   > global symbol which infringes on the ANSI C namespace.  The symbol
   > must, instead, be weak.

   Why should `glob' be made weak?  In GNU libc we make a symbol only
   weak if necessary.  It is correct that no symbol in a ISO C lib
   must have this name.  But if the object file in the shared lib which
   contains the definition of glob is transitively not used by any ISO C
   function this is ok.  At least this is what I currently know.

That turns out not to be the case.  A shared library is not like an
archive library.  A shared library is a single object.  Everything
that composes a shared library is linked together.  There is only one
set of symbols.  There is no way for the linker to form any sort of
transitive closure operation, because there is no longer any
distinction between the various object files which compose the shared
library.

   Reading your words it seems that using a shared lib introduces *all*
   symbols of the shared lib in the namespace of the application.  I.e.,
   all symbols not mentioned in ISO C must be weak.  Is this how it is
   implemented in GNU ld and how it is intend in ELF?

Yes.

That's how it's implemented in any ELF linker.

   If yes, this would mean that nearly every symbol in the shared lib
   must be weak.

Right.  Every symbol in the ANSI C namespace must be weak (in other
words, you don't have to worry about symbols which start with
underscore).  If you look at libc.so on an SVR4 system, that is what
you will see.

Ian