Re: global vars and symbol visibility for mips32/elf

[Ruediger Helsch <rh@unifix.de>]

On Sat, 10 Aug 1996, Ian Lance Taylor wrote:

> The case which causes trouble is when a program uses a common variable
> (an uninitialized variable in C; most languages, including C++, have
> no notion of common variables).  A common variable is treated as an
> undefined reference, unless no definition is seen.  In the latter
> case, the common variable becomes a definition.
> 
> When a common variable is used, the linker will resolve it against a
> definition found in a shared library.  This is different from the
> handling of an archive library, at least in ELF.  In an ELF archive
> library, a particular object will not be included in the link merely
> to satisfy a common reference; it will only be included to satisfy an
> undefined reference.
> 
> In some cases, it will be desirable to resolve a common symbol with
> the definition in the shared library.  This would be desirable when
> the actual intent was to use the initialized variable in the shared
> library.  For example, if a program uses ``int optind;'' rather than
> ``extern int optind;'', and it also calls getopt, then, in both a
> shared library and an archive library, the common symbol optind will
> wind up referring to the initialized variable optind, rather than
> creating a new, uninitialized, optind variable.

Wrong.  A standard conforming compiler will conclaim about a multiply
defined symbol.

This problem has been avoided by the C standard by forbidding COMMON
generation (ISO/IEC 9899:1990 6.7.2).  Unfortunately GCC generates
commons even when -ansi is specified.  In either case it is not
desirable to link commons against functions, which solves the problem
without disabling commons.

Ruediger Helsch <rh@unifix.de>