error: conflicting types for 'psignal'

[Michael Zintakis]

>> -I. -I/home/mz/gcc-test/build/src/gcc-4.5.2/libiberty/../include  -W
>> -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic
>> /home/mz/gcc-test/build/src/gcc-4.5.2/libiberty/strsignal.c -o
>> strsignal.o
>> /home/mz/gcc-test/build/src/gcc-4.5.2/libiberty/strsignal.c:554:1:
>> error: conflicting types for 'psignal'
>> /home/mz/gcc-test/install/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu/sysroot/usr/include/signal.h:150:13:
>> note: previous declaration of 'psignal' was here
>>     
>
> This means that the libiberty configure script decided that your system
> did not provide the psignal function, although it apparently does.
>   
It is very interesting what I just found! The crosstool-ng has a patch 
for the (older) version of binutils (2.20.1) - I am currently using 
2.21, so no patches are applied - called "libiberty-pic.patch", which 
adds a single line "cp ${TARGETLIB} ../ ; \" to the Makefile.in in 
liberty directory from the main binutils source tree. I am hoping this 
patch deals with exactly that problem because much earlier versions of 
this patch (for binutils 1.16.1) has a detailed explanation of what you 
just summarised in your last paragraph above.

So, I have just moved this patch to my 2.21 tree and will see if it 
fixes the problem (I have to wait about 40+ minutes though as this error 
appears much later in the whole process when I am building the final 
version of the gcc compiler, which is the last step of the whole build up!).

> Look at libiberty/config.log to see if you can find out why libiberty
> thinks your system does not support psignal.
>   
The config.log has exit code of 0 and "#define HAVE_PSIGNAL 1" as well 
as the actual test returning a result "yes", so I am assuming that 
everything is OK.