This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GNU/Linux vs. libtool --no-undefined


On Tue, Feb 06, 2001 at 04:55:49PM +0100, Andreas Schwab wrote:
> Fergus Henderson <fjh@cs.mu.oz.au> writes:
> 
> |> On 06-Feb-2001, Andreas Schwab <schwab@suse.de> wrote:
> |> > Mark Mitchell <mark@codesourcery.com> writes:
> |> > 
> |> > |> First, libtool didn't actually do anything with --no-undefined on
> |> > |> GNU/Linux.  It took a while to figure that out.
> |> > |> 
> |> > |> Second, I get:
> |> > |> 
> |> > |> /lib/libc.so.6: undefined reference to `_dl_init_next@GLIBC_2.0'
> |> > |> /lib/libc.so.6: undefined reference to `_dl_lazy@GLIBC_2.1.1'
> |> > |> 
> |> > |> These symbols are defined in ld-linux.so.  Is it reasonable to link
> |> > |> against that library, or is that harmful?  I know it isn't necessary,
> |> > |> but does it hurt?
> |> > 
> |> > You should never link against /lib/libc.so.6 directly, but only via
> |> > /usr/lib/libc.so (which is a linker script that includes the necessary
> |> > libraries).  This takes care of linking in ld-linux*.so.* (using the
> |> > correct name, which differs among architectures) and libc_nonshared.a
> |> > (which defines some symbols that must not be defined by libc itself).
> |> 
> |> Hmm, it doesn't seem to work that way on my Debian Linux system.
> |> On this system, which uses libc-2.2.1, /usr/lib/libc.so contains only
> |> the following four lines:
> |> 
> |> 	/* GNU ld script
> |> 	   Use the shared library, but some functions are only in
> |> 	   the static library, so try that secondarily.  */
> |> 	GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
> 
> Yes, you are right.  I was confusing it with DT_NEEDED.
> 
> |> Note that there is no mention of ld-linux*.so*.
> |> If I link the Mercury runtime library with --no-undefined then I get
> |> similar errors about `undefined reference to `_dl_*', which go away if
> |> I explicitly link with `/lib/ld-linux.so.2' by adding it at the end
> |> of the linker invocation line.
> 
> Sounds like a linker bug, since ld-linux.so.2 does already get linked in
> via DT_NEEDED.
> 

Here is the code in question:

/* This is called after all the input files have been opened.  */

static void
gld${EMULATION_NAME}_after_open ()
{
  struct bfd_link_needed_list *needed, *l;

  /* We only need to worry about this when doing a final link.  */
  if (link_info.relocateable || link_info.shared)
    return; 

in ld/emultempl/elf32.em. DT_NEEDED is not searched for building DSOs.
I am not sure if it should. One way to fix glibc is to add
/lib/ld-linux.so.2 to /usr/lib/libc.so.

-- 
H.J. Lu (hjl@valinux.com)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]