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]|
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 <email@example.com>