libiberty strsignal changes cause windows compilation breakage

[Chris Faylor <cgf at cygnus dot com>]

The strsignal file in libiberty was recently updated to include
"string.h".  This has an unpleasant side effect on cygwin in that the
declaration for strsignal in newlib's string.h is essentially this:

char *strsignal (int sig);

while the definition in strsignal.c is:

const char *strsignal (int sig)

This is interesting since cygwin's version of strsignal comes from
libiberty.

To rectify this, I changed the declaration of strsignal in newlib to
conform to the definition in strsignal.c.

This now breaks gdb, which has its own declaration of strsignal in
defs.h.  It does not include the 'const', of course.

I can easily work around this problem by adding an '#ifndef __CYGWIN__"
around the defs.h declaration but I always hate adding system specific
ifdefs if they can be avoided.

Can anyone offer any other suggestions so that I can get gdb building
again?  The way that this was solved in 1997 was to remove the const
from the declaration in newlib's string.h.  I don't think that's the
correct solution here.

Possibly the correct solution is to remove the const in strsignal.c
but that will take some effort to get approved.  And, with the current
implementation of strsignal, the const is actually correct.  I really
don't want to rewrite strsignal just to fix cygwin/gdb.  This file
seems to have been untouched for some time.

Any suggestions would be appreciated.

cgf