Dave Korn wrote:
> Andy Scott wrote:
>> ../../../gcc/libiberty/strsignal.c -o strsignal.o
>> ../../../gcc/libiberty/strsignal.c:408: error: conflicting types for
>> 'strsignal'
>> /usr/include/string.h:78: note: previous declaration of 'strsignal' was here
>> make[2]: *** [strsignal.o] Error 1
>> make[2]: Leaving directory
>> `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty'
>> make[1]: *** [all-target-libiberty] Error 2
>> make[1]: Leaving directory `/home/andy/live-gcc/my_gcc'
>> make: *** [all] Error 2
>>
>> Which seems like a possible setup/build issue. If this is so anyone
>> seen it before and any helpful hints on how to get rid of it?
>
> Looks like newlib has a non-posix-compliant definition of strsignal. If
> you take a look at the header file, it seems GDB has a problem with it too:
>
> /tmp/binutils/binutils-2.19/ld $ cat -n /usr/include/string.h | grep -C4 78
> 74 char *_EXFUN(strlwr,(char *));
> 75 char *_EXFUN(strupr,(char *));
> 76 #ifdef __CYGWIN__
> 77 #ifndef DEFS_H /* Kludge to work around problem compiling in gdb */
> 78 const char *_EXFUN(strsignal, (int __signo));
> 79 #endif
> 80 int _EXFUN(strtosigno, (const char *__name));
> 81 #endif
> 82
> /tmp/binutils/binutils-2.19/ld $
>
> ... maybe just adding -DDEFS_H to your CFLAGS would be a work-around. Hmm,
> given that Cygwin supports strsignal, this bit of libiberty shouldn't be being
> compiled, because configure should have defined HAVE_STRSIGNAL. On my local
> build of 4.3.2, this works correctly: "nm libiberty/strsignal.o" shows the
> function isn't defined, and HAVE_STRSIGNAL is defined in config.h. Have a
> look through libiberty/config.log and see if you can figure out why it isn't
> defined; maybe it's even something to do with the earlier crash?
I've now run into this locally and am debugging it. I think that the
definition or possibly even existence of strsignal in cygwin may have shifted
the ground slightly under libiberty's feet.
cheers,
DaveK
