This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: libiberty strsignal changes cause windows compilation breakage
- To: ac131313 at cygnus dot com
- Subject: Re: libiberty strsignal changes cause windows compilation breakage
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Fri, 2 Jun 2000 00:07:32 +0200
- CC: cgf at cygnus dot com, gdb at sourceware dot cygnus dot com
- References: <20000531182910.A29100@cygnus.com> <3935FB36.DB834E7A@cygnus.com>
Date: Thu, 01 Jun 2000 15:57:10 +1000
From: Andrew Cagney <ac131313@cygnus.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.
It's marked as a GNU extension in the GNU C Library. The copyright
date on the file that implements it suggests that it was created in
1991. The first ChangeLog entry mentioning strsignal() is from April
1992. If you're really interested you could ask Roland McGrath.
Both Solaris and FreeBSD have strsignal() too. In all three cases
it's prototype is:
extern char *strsignal (int);
So I'd suggest aligning libiberty with the rest of the world.
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 :-)
I'll be happy to look the other way :-)
Mark