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: Chris Faylor <cgf at cygnus dot com>
- Subject: Re: libiberty strsignal changes cause windows compilation breakage
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 01 Jun 2000 15:57:10 +1000
- CC: gdb at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <20000531182910.A29100@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.
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