Re: ld and common symbols (fwd)

Re: ld and common symbols (fwd)

[Ulrich Drepper]

[Phil used libc-hacker@gnu.org which ends up in my mail box.]

The linker issue in the message below seems to be preventing libc from 
building properly on my machines.  What happens is that, when building
ld.so, the common definition of __libc_multiple_libcs in dl-sysdep.os 
is no longer sufficient to stop init-first.os from being sucked into 
librtld.os.  This actually manifests as __libc_global_ctors being 
undefined when linking with ld-linux.so.2.  (Entertainingly, the deliberate
multiple definition of _dl_start in init-first.c doesn't seem to be doing
its job of preventing the link; we just end up with two _dl_start's in 
ld.so.  I think that is because the copy in rtld.c is defined `static'.).

This is with the 2.1 branch, I haven't tried 2.2.  Has anybody else come 
across this?

Thanks

p.

------- Forwarded Message

Date: Tue, 21 Dec 1999 13:50:23 -0800
Message-Id: <199912212150.NAA16520@elmo.cygnus.com>
From: Nick Clifton <nickc@cygnus.com>
To: Philip.Blundell@pobox.com
CC: binutils@sourceware.cygnus.com
Subject: Re: ld and common symbols

Hi Phillip,

: Using the latest binutils from CVS I am seeing what seems to be a change in 
: behaviour relating to ld and common symbols.
: 
: With a test like this:
: 
: $ cat >t1.c
: int foo;	/* common */
: int bar = 1;	/* initialised */
: ^D
: $ cat >t2.c
: int foo = 1;	/* initialised */
: int bar = 1;	/* initialised */
: ^D
: $ gcc -c t1.c
: $ gcc -c t2.c
: $ ar cq t.a t2.o
: $ ld t1.o t.a
: 
: older versions of the linker seemed to be content with the common declaration 
: of `foo' in t1.o.  The current linker instead favours pulling in the archive 
: member in order to get an initialised definition of `foo'.  In this case that 
: causes `bar' to be multiply defined and so you get a link error.
: 
: This patch seems a likely candidate for having caused the change, though I 
: haven't verified that this is the case.
: 
: 1999-12-10  Nick Clifton  <nickc@cygnus.com>
: 
: 	* elflink.h (elf_link_is_defined_archive_symbol): New
: 	function: Decide if a symbol, in an archive map is there
: 	because it is defined in the archive element, or because it is
: 	just another common declaration of it.
: 	(elf_link_add_archive_symbols): Use
: 	elf_link_is_defined_archive_symbol to decide if an archive
: 	element contain a reference to a common symbol should be
: 	linked in or not.
: 
: Can anybody explain whether the "new" behaviour is intentional or accidental?

It is intentional.

This change is in order to match the behaviour of the native linkers
for Solaris and HP-UX (and possibly others, we haven't tested), and is
also necessary in order to allow libraries of FORTRAN generates
objects to be correctly linked together.

I think we would all agree that if t2.c had contained this line:

  int bar = 2;

then the linker would have been justified in issueing the error about
a multiply defined symbol.  I am not sure however, what the concessus
will be for the correct behaviour in the case you outline above.
Persoanlly I think the linker is doing the right thing in complaining,
since bar ought to only be defined and initlaised in one palce, and
the other files ought to just contain references to it.

Cheers
	Nick


------- End of Forwarded Message

Re: ld and common symbols (fwd)

[Ulrich Drepper]

Ulrich Drepper <drepper@cygnus.com> writes:

> The linker issue in the message below seems to be preventing libc from 
> building properly on my machines.  What happens is that, when building
> ld.so, the common definition of __libc_multiple_libcs in dl-sysdep.os 
> is no longer sufficient to stop init-first.os from being sucked into 
> librtld.os.

I haven't seen a problem so far but will keep an eye on it and talk to
Nick.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: ld and common symbols (fwd)

[NIIBE Yutaka]

Philip.Blundell@pobox.com wrote:
 > The linker issue in the message below seems to be preventing libc from 
 > building properly on my machines.  What happens is that, when building
 > ld.so, the common definition of __libc_multiple_libcs in dl-sysdep.os 
 > is no longer sufficient to stop init-first.os from being sucked into 
 > librtld.os.  This actually manifests as __libc_global_ctors being 
 > undefined when linking with ld-linux.so.2.  (Entertainingly, the deliberate
 > multiple definition of _dl_start in init-first.c doesn't seem to be doing
 > its job of preventing the link; we just end up with two _dl_start's in 
 > ld.so.  I think that is because the copy in rtld.c is defined `static'.).
 > 
 > This is with the 2.1 branch, I haven't tried 2.2.  Has anybody else come 
 > across this?
 > 
 > Thanks

Just got a same problem for SuperH port for 2.1.2.  Changing

     int __libc_multiple_libcs = 0;

in dl-sysdep.os (add the initialization = 0), as current libc does
solves the problem.

I guess that the reason is that symbol goes to .data section instead
of .common section with the initialization.
-- 
Niibe Yutaka