This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: --unresolved-symbols patch breaks autoconf tests
- From: Nick Clifton <nickc at redhat dot com>
- To: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>, dj at redhat dot com
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 02 Oct 2003 15:01:58 +0100
- Subject: Re: --unresolved-symbols patch breaks autoconf tests
- References: <16235.21190.636525.427919@xayide.TechFak.Uni-Bielefeld.DE><m3r81wx9gk.fsf@redhat.com><16252.5722.679515.723756@xayide.TechFak.Uni-Bielefeld.DE>
Hi Rainer,
> ~/gld-2.14.90 -v -call_shared -init __do_global_ctors -fini __do_global_dtors -melf32bmipn32 -o nosf /usr/lib32/mips3/crt1.o ./crtbegin.o -L. -L/usr/bin nosf.o -lgcc -lgcc_eh -L/usr/lib32/mips3 -L/usr/lib32 -lc -lgcc -lgcc_eh ./crtend.o /usr/lib32/mips3/crtn.o
> GNU ld version 2.14.90 20031002
> nosf.o(.text+0x20): In function `main':
> : warning: undefined reference to `nosuchfunction'
> `ignore-all'
> Do not report any unresolved symbols. This is the default
> when creating shared libraries or dynamic executables.
>
> 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
happens at load time, and it is not possible to guarantee that the
shared libraries available at link time will be exactly the same as
the shared libraries available at load time.
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 ?
Cheers
Nick