gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On linux too (was Re: Base compilation broken on NetBSD)


From: Wolfgang Lux
Subject: Re: On linux too (was Re: Base compilation broken on NetBSD)
Date: Fri, 2 Nov 2012 14:50:34 +0100

Wolfgang Lux wrote:

> I was going about to write the test, but then I found that autoconf already 
> has a predefined test for it (obviously, we are not the only ones struggling 
> with this dichotomy :-)
> 
> -- Macro: AC_FUNC_STRERROR_R
>     If `strerror_r' is available, define `HAVE_STRERROR_R', and if it
>     is declared, define `HAVE_DECL_STRERROR_R'.  If it returns a `char
>     *' message, define `STRERROR_R_CHAR_P'; otherwise it returns an
>     `int' error number.  The Thread-Safe Functions option of Posix
>     requires `strerror_r' to return `int', but many systems
>     (including, for example, version 2.2.4 of the GNU C Library)
>     return a `char *' value that is not necessarily equal to the
>     buffer argument.
> 
> So instead of using
> AC_CHECK_FUNCS(strerror_r strerror)
> in configure.ac, we should be using
> AC_CHECK_FUNCS(strerror)
> AC_FUNC_STRERROR_R
> and add STRERROR_R_CHAR_P to config.h.in and use it to select a suitable 
> variant of the code in the _systemError: method.

I have implemented this. The configure script checks for the variant of 
strerror_r and the _systemError: method now contains code for the glibc variant 
of strerror_r. Doing that, I had to remove the code from common.h that was 
undefining _GNU_SOURCE and conditionally defining _XOPEN_SOURCE, as that could 
invalidate the result of the autoconf test. I tested this on both OS X (using 
the POSIX variant) and Linux (using the glibc version) and this seems to work. 
I think it should also work for systems where strerror_r is not defined at all 
and we define our own, POSIX compatible version, but I have no system to test 
this.

Wolfgang




reply via email to

[Prev in Thread] Current Thread [Next in Thread]