This is the mail archive of the firstname.lastname@example.org mailing list for the gas2 project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
Date: Fri, 09 Aug 1996 13:13:00 -0700 From: Ulrich Drepper <email@example.com> From: Ian Lance Taylor <firstname.lastname@example.org> 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