This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: --unresolved-symbols patch breaks autoconf tests


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
        


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]