Re: --unresolved-symbols patch breaks autoconf tests

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

Hi Nick,

> [Sorry for the delay in replying - I have been on vacation]

no problem, I've knew that (and could work around the problem by adding -z
defs to the affected LINK_SPEC's, but this is only a hack, not a solution).

> Does this problem still exist for you ?
> 
> I tried building using the latest gcc and binutils sources and it
> appears to work:
> 
>   % ../gcc/xgcc -B ../gcc/ nosf.o
>   nosf.o(.text+0x11): In function `main':
>   : undefined reference to `nosuchfunction'
>   collect2: ld returned 1 exit status
>   % echo $?
>   1

Unfortunately, it does:

~/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'
ro@columba 1434 > echo $?
0

I think the error is here (from
http://sources.redhat.com/ml/binutils/2003-08/msg00319.html):

`--unresolved-symbols=METHOD'
     Determine how to handle unresolved symbols.  There are four
     possible values for `method':

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

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University