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