This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC 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: error: conflicting types for 'psignal'


On Thu, Mar 17, 2011 at 6:55 PM, Michael Zintakis
<michael.zintakis@googlemail.com> wrote:
>
>>> -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.
>>

Michael,

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

I'm sure Yann can give a better explanation, but we decided to stop
moving patches to newer versions of source components in crosstool-ng
until we can verify the patches with upstream maintainers.

I guess this would be a great time to ask if we can get this patch
merged upstream or at least check the validity of the patch with Ian.

Either way, thanks for testing the patch. Please let us know how the build goes.

-Bryan


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