[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On linux too (was Re: Base compilation broken on NetBSD)
From: |
Richard Frith-Macdonald |
Subject: |
Re: On linux too (was Re: Base compilation broken on NetBSD) |
Date: |
Sat, 3 Nov 2012 15:42:21 +0000 |
On 2 Nov 2012, at 13:50, Wolfgang Lux wrote:
> 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.
Thnaks Wolfgang, that looks good.
- Re: On linux too (was Re: Base compilation broken on NetBSD), (continued)
- Re: On linux too (was Re: Base compilation broken on NetBSD), Wolfgang Lux, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), David Chisnall, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), Wolfgang Lux, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), Richard Frith-Macdonald, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), Wolfgang Lux, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), Wolfgang Lux, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), Richard Frith-Macdonald, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), Wolfgang Lux, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), Wolfgang Lux, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), Philippe Roussel, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD),
Richard Frith-Macdonald <=
- Re: On linux too (was Re: Base compilation broken on NetBSD), Richard Frith-Macdonald, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), David Chisnall, 2012/11/02
- Re: On linux too (was Re: Base compilation broken on NetBSD), David Chisnall, 2012/11/02