Re: Confusing meaning of --no-undefined

[Jan Vroonhof <jan dot vroonhof at insignia dot com>]

"H. J. Lu" <hjl@lucon.org> writes:

> [don't complain about undefined symbols in bar.so is intentional as
> there is no guarantee the runtime .so is the same]
>> 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 know. But in the case of an executable, you do warn about missing
symbols in shared libraries on the link line. Even though in that case
there also is no guarantee that the shared library will be the same.

The second point this that the case of the executable proves that the
linker still can do it.

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

Again I know. That is why --no-undefined is off by default.  But in my
case I have all the objects in question available (or at least
compatible copies) and I want to check that is indeed the case.
That is presumably also why -Bgroup turns it on by default. 

> If you know what bar.so will be used at the run-time, you can check
> the undefined symbols at the run-time.

Two problems here 1. I often cannot 2. I don't want to.

Ad 1. We do a lot of cross-compiling in which case I cannot really run
the runtime as part of the build process.

Ad 2. The whole point of this is that I want to do this check at build
time. Waiting for somebody (or something) to try actually using the
library at runtime simply isn't as good.

The 1-library only behavior of --no-undefined comes a long way, but it
would be nice to have the old (executable like) behavior as well.

> It may be useful to have another
> option, --no-undefined-shlib, in your case. But the current behavior
> should be the same by default.

Fine with me. However I would suggest this set of options could do
with clearer documentation.

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

Sorry, I don't see why your are referencing these articles. I know the
change was made :-). Are you arguing that it was the way it was
supposed to work right from the start and the 2.11 behavior was a bug?

May also humbly suggest that in my opinion this new(old?) behavior is
not really fixing the problem reported in the 2001-06 (which is an
incarnation of the libc refers to symbols in the dynamic linker
problem). (at least modern) glibc libc.so.6 declare a NEEDED
dependency on ld-linux.so.2 why isn't the linker following it.

Jan