From deleeuw@stat.ucla.edu  Wed Jan  2 23:02:24 2002
From: deleeuw@stat.ucla.edu (Jan de Leeuw)
Date: Wed, 2 Jan 2002 15:02:24 -0800
Subject: [Rd] multiple definitions in C code
Message-ID: <C8FC28E2-FFD4-11D5-B79D-00039319314A@stat.ucla.edu>

There is a problem in MacOS X with multiple definitions of the same
symbol in different files that will be put into the same bundle or
dynamic library by the dynamic linker. It occurs, for example, in
the rpart package, which includes rpart.h in all its source files,
and rpart.h has definitions of a structure rp and functions rp_init
and so on. I think the same problem occurs in the grid package --
all 150+ others seem to be fine. Just out of curiosity, I looked into
the problem a bit, in particular as it relates to dyld in OS X.

==========================================================================
====
According to the ANSI Standard

G.5 Common Extensions

The following extensions are widely used in many systems, but are not
portable to all implementations. The inclusion of any extension that may 
cause
a strictly conforming program to become invalid renders an implementation
non-conforming.

...

G.5.11 Multiple external definitions

There may be more than one external definition for the identifier of an 
object,
with or without the explicit use of the keyword extern. If the 
definitions
disagree, or more than one is initialized, the behavior is undefined.
==========================================================================
====
See also Summit, C Programming FAQ, section 1.7, or Koenig, C Traps and
Pitfalls, pages 54-56. Portability considerations makes them suggest 
that the
safe way to proceed is to have only a single definition, in a source 
file, with
or without initialization, and everywhere else (in header files) external
declarations.
==========================================================================
====
 From the MacOS X ld man page:

Different linking can occur only when there  is  more
than  one  definition  of a symbol and the library modules
that contain the definitions for that symbol do not define
and  reference  exactly  the  same symbols.  In this case,
even different executions of the same program can  produce
different  linking  because the dynamic linker binds unde-
fined functions as they are called, and this  affects  the
order  in  which  undefined symbols are bound.  Because it
can  produce  different  dynamic  linking,  using  dynamic
shared  libraries that define the same symbols in the same
program is strongly discouraged.
==========================================================================
====
 From Inside Mac OS X (page 134)

When you create a framework, you must ensure that each symbol
is defined only once in a library. In addition, "common" symbols
are not allowed in the library, you must use a single true definition
and precede all other definitions with the extern key word in C
code.
==========================================================================
====

Thus we see that the dynamic linker sets things up for "lazy
linking", where symbols are loaded at run time if they are actually
needed (and not at startup). It is different, I think, from Solaris
(see Solaris Porting Guide, p. 102-103), which also has "lazy
linking", but allows multiple definitions ("the first one wins").

The gcc compiler has a flag -fno-common (Stallman, p. 187), which 
allocates
space for each defined variable directly, and does not place it in
"common" space. The Next dynamic linker has a flag -m, which
makes multiple definitions into warnings instead of errors.
This if we have files galadriel.c with

==========================================================================
====
#include <stdio.h>

float bilbo;

int galadriel ()
{
bilbo = 1.0;
return printf("%1.0f\n", bilbo + bilbo);
}
==========================================================================
====

and elrond.c with

==========================================================================
====
#include <stdio.h>

int bilbo;

int elrond()
{
bilbo = 1;
return printf("%d\n", bilbo + bilbo);
}
==========================================================================
====

and we compile them with -fno-common, then we cannot link them
into either an executable (with a suitable main) or into a bundle.
If we leave out -fno-common, then we can. Linking into an
executable will lead to undefined but unambiguous behavior, linking 
into a
dynamic library could lead to different behaviors at different
occasions at run time. Thus

[localhost:~/Desktop/rings] deleeuw% gcc -c -fno-common elrond.c
[localhost:~/Desktop/rings] deleeuw% gcc -c -fno-common galadriel.c
[localhost:~/Desktop/rings] deleeuw% nm -pg elrond.o
000000a8 S _bilbo
00000000 T _elrond
          U _printf
          U dyld_stub_binding_helper
[localhost:~/Desktop/rings] deleeuw% nm -pg galadriel.o
000000c0 S _bilbo
00000000 T _galadriel
          U _printf
          U dyld_stub_binding_helper

and then

[localhost:~/Desktop/rings] deleeuw% gcc -bundle -o rings.so elrond.o 
galadriel.o
/usr/bin/ld: multiple definitions of symbol _bilbo
elrond.o definition of _bilbo in section (__DATA,__common)
galadriel.o definition of _bilbo in section (__DATA,__common)
[localhost:~/Desktop/rings] deleeuw% gcc -bundle -o rings.so -Xlinker -m 
elrond.o galadriel.o
/usr/bin/ld: warning multiple definitions of symbol _bilbo
elrond.o definition of _bilbo in section (__DATA,__common)
galadriel.o definition of _bilbo in section (__DATA,__common)
[localhost:~/Desktop/rings] deleeuw% nm -pg rings.so
00001018 S _bilbo
00000ecc T _elrond
00000f44 T _galadriel
          U _printf

  while

[localhost:~/Desktop/rings] deleeuw% gcc -c elrond.c
[localhost:~/Desktop/rings] deleeuw% gcc -c galadriel.c
[localhost:~/Desktop/rings] deleeuw% gcc -bundle -o rings.so elrond.o 
galadriel.o
[localhost:~/Desktop/rings] deleeuw% nm -pg elrond.o
00000000 T _elrond
00000004 C _bilbo
          U _printf
          U dyld_stub_binding_helper
[localhost:~/Desktop/rings] deleeuw% nm -pg galadriel.o
00000000 T _galadriel
00000004 C _bilbo
          U _printf
          U dyld_stub_binding_helper
[localhost:~/Desktop/rings] deleeuw% nm -pg rings.so
00001020 S _bilbo
00000ecc T _elrond
00000f44 T _galadriel
          U _printf

but now

[localhost:~/Desktop/rings] deleeuw% gcc -dynamiclib -o librings.dylib 
elrond.o galadriel.o
ld: common symbols not allowed with MH_DYLIB output format
elrond.o definition of common _bilbo (size 4)
/usr/bin/libtool: internal link edit command failed


Of course we can use ar to put the object files in an archive, but if a 
symbol
is defined (and initialized) more than once the table of contents cannot 
be
sorted by ranlib.


===
Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554
phone (310)-825-9550;  fax (310)-206-5658;  email: deleeuw@stat.ucla.edu
homepage: http://www.stat.ucla.edu/~deleeuw
========================================================
           No matter where you go, there you are. --- Buckaroo Banzai
                    http://www.stat.ucla.edu/~deleeuw/sounds/nomatter.au
========================================================

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] multiple definitions in C code
Jan de Leeuw