Re: error: conflicting types for 'psignal'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 17, 2011 at 6:55 PM, Michael Zintakis
<michael.zintakis@xxxxxxxxxxxxxx> 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 of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux