Confusing meaning of --no-undefined
H. J. Lu
hjl@lucon.org
Tue Feb 11 20:24:00 GMT 2003
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.
More information about the Binutils
mailing list