Re: libiberty strsignal changes cause windows compilation breakage

[Andrew Cagney <ac131313 at cygnus dot com>]

Chris Faylor wrote:
> 
> 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:

POSIX doesn't appear to list strsignal().  Would you know its history? 
First thing is to figure out what the definition should be according to
a standard rather than someones passing whim.

As an example of this, check ``basename()'' - POSIX specifies:
http://www.opengroup.org/onlinepubs/007908799/xsh/basename.html
	#include <libgen.h>
	char *basename(char *path);
yet include/libiberty.h defines:
	extern char *basename PARAMS ((const char *));
I've a things-to-do-today to fix it :-)

> while the definition in strsignal.c is:
> 
> const char *strsignal (int sig)

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

This can be tested using some configury.  If <string.h> define it then
don't bother providing a definition (perhaphs in "gdb_string.h".

Hmm, find | grep strsignal

	convex-tdep.c:/* OBSOLETE */strsignal()
	corelow.c: safe_strsignal()
	sun386-nat.c:safe_strsignal()
	umax-xdep.c:safe_strsignal()

and utils.c defines save_strsignal().  Shouldn't corelow.c be calling
target_signal_to_string()? I'll ignore sun386-nat.c and umax-xdep.c as
we could probably slip in a ``OBSOLETE'' while no one was looking :-)

	Andrew