Re: Confusing meaning of --no-undefined

["H. J. Lu" <hjl at lucon dot org>]

On Tue, Feb 11, 2003 at 07:20:11PM +0000, Jan Vroonhof wrote:
> 
> [Thanks Nick for following up on this!]
> 
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > I believe we have gone through it before. Since bar.so is not the
> > part of the resulting DSO, I don't see why ld should complain. Even
> > if ld checks bar.so at the link-time, we don't know if the run-time
> > bar.so is the same one.
> 
> But doesn't the same thing hold for links into executables as well?
> Why should shared libraries be different?

--no-undefined is for shared libraries. It isn't needed for linking
executables.

> 
> i.e. if my shared library is dlopen()end using the libraries as linker
> can see them now will it work?

Your shared library can use any global objects which may satisfy those
undefined references.

> 
> > If you want to ensure there is no undefined
> > symbol in bar.so, you should do
> >
> > # ld --share --no-undefined -o bar.so ...
> 
> In our case bar.so is built by some other party, not necessarily with
> all its DT_NEEDED information correct etc..

If you know what bar.so will be used at the run-time, you can check
the undefined symbols at the run-time. It may be useful to have another
option, --no-undefined-shlib, in your case. But the current behavior
should be the same by default.

> 
> My main point is this changed between 2.11 and 2.12 without any
> change in the documentation.

See

http://sources.redhat.com/ml/binutils/2001-06/msg00670.html
http://sources.redhat.com/ml/binutils/2001-02/msg00092.html

> 
> So basically in an ideal world I would want
> 
> 1. Switches to enable both behaviors
>    Suggestion, i.e. combine with --[no-]allow-shlib-undefined?
> 
> i.e.
> --no-undefined  --allow-shlib-undefined
> no error for undef symbols in bar.o
> --no-undefined  --no-allow-shlib-undefined
> error for undef symbols in bar.o
> 
> 2. Documentation that clarifies which of the two behaviors is enabled by
>   --no-undefined.
> 


H.J.