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]|
From: Ian Lance Taylor <email@example.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. 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? If yes, this would mean that nearly every symbol in the shared lib must be weak. Thanks, -- Uli --------------. firstname.lastname@example.org ,-. Rubensstrasse 5 Ulrich Drepper \ ,--------------------' \ 76149 Karlsruhe/Germany Cygnus Support `--' email@example.com `------------------------