GNU/Linux vs. libtool --no-undefined

[Fergus Henderson]

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 )

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.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.