Confusing meaning of --no-undefined

[Jan Vroonhof]

[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?

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

> 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..

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

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.

Jan