This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: GNU/Linux vs. libtool --no-undefined
- To: Andreas Schwab <schwab at suse dot de>
- Subject: Re: GNU/Linux vs. libtool --no-undefined
- From: "H . J . Lu" <hjl at valinux dot com>
- Date: Tue, 6 Feb 2001 11:29:28 -0800
- Cc: Fergus Henderson <fjh at cs dot mu dot oz dot au>,binutils at sourceware dot cygnus dot com,Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org
- References: <20010205211708R.mitchell@codesourcery.com> <jebssgkl77.fsf@hawking.suse.de> <20010207024456.A10994@venus.cs.mu.oz.au> <jeu2673iwq.fsf@hawking.suse.de>
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)