Re: --unresolved-symbols patch breaks autoconf tests

[Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>]

Hi Nick,

> > It cannot work to ignore unresolved symbols for dynamic executables: they
> > must be resolved at link time, just as for static executables.
> 
> Err, why ?  I understood that dynamic executables (ie ones linked
> against shared libraries) could have unresolved symbols at link
> time.  The reason being that the true resolution of these symbols

I don't think so: I've never seen a system where this would be the case.
It may be possible to occur in unusal cases, but must never be the default.

> It seems to me that one way to resolve this problem would be to change
> the autoconf tests to add "--no-allow-shlib-undefined" when running
> the libiberty tests.  Either that or always try to link a static
> binary, so that the linker will fail upon encountering unresolved
> symbols.  DJ - Is this easy to do ?

This is not only a libiberty problem, but a problem for all packages using
autoconf and the AC_CHECK_FUNCS macro: it just doesn't work to upgrade GNU
ld and suddenly having to (retrospectively!) upgrade the implementation of
that macro for all users of configure to accomodate that changed default.
That's an incompatible change of the worst possible sort, since this
doesn't happen with either older versions of GNU ld or any other vendor
linker I know.

	Rainer