Re: A patch for elf32.em (Re: GNU/Linux vs. libtool --no-undefined)

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Wed, 7 Feb 2001 12:14:04 -0800
> From: "H . J . Lu" <hjl@valinux.com>
> Cc: aoliva@redhat.com, ian@zembu.com, fjh@cs.mu.oz.au,
>         binutils@sourceware.cygnus.com
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i
> 
> On Wed, Feb 07, 2001 at 12:06:43PM -0800, Geoff Keating wrote:
> > 
> > I think we should have options that can handle both cases.  It's easy
> > to come up with a situations where each case are useful.
> > 
> 
> I don't know how useful it will be. I agree with Ian that it doesn't
> make much sense to warn about the undefined symbols in the DSOs you
> are linking against when you are building a DSO. It is very possible
> that those undefined symbols may change/disappear/be different from
> the runtime version.

I would expect that the common case is that the version you are
linking against, and the version you are running with, will be the
same.

If a DSO used to be complete, and then one of the DSOs it was linked
against is changed and it is not complete any more, and it's supposed
to be complete, I would think that this is a problem.  But I don't see
how the linker can detect that.  However, the linker can detect if it
was never complete in the first place, and this seems to me to be a
reasonable thing to check.

The problem can also be detected at dlopen() time, if RTLD_NOW is passed,
but it's better to try to catch as many problems as possible at
compile time.

-- 
- Geoffrey Keating <geoffk@geoffk.org>