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: Richard Frith-Macdonald
Subject: Re: On linux too (was Re: Base compilation broken on NetBSD)
Date: Fri, 2 Nov 2012 10:13:08 +0000

On 2 Nov 2012, at 10:00, Wolfgang Lux wrote:

> Wolfgang Lux wrote:
> 
> 
>>> Yes you NEED _XOPEN_SOURCE ... because it selects which, of different 
>>> variant of some functions, you actually get to use.
>>> So without it the code may compile but not run correctly.
>>> 
>>> The example that springs to mind is strerror_r() ... if you don't have it 
>>> defined then any system error messages in NSError or in logs will contain 
>>> garbage.
>> 
>> Sorry for being dumb (and for not reading the comment in common.h, which 
>> said exactly that). But if this only affects the strerror_r function, 
>> wouldn't it be simpler to have two versions of the code in the _systemError: 
>> method (one for the GNU version and one for the POSIX version) instead of 
>> this nasty fiddling with preprocessor macros that seems hard to get right 
>> for everyone?
> 
> And even worse, it doesn't seem to be necessary on newer Linux systems too, 
> given this comment from the strerror_r man page:
>  If no feature test  macros  are  explicitly   defined,   then   (since   
> glibc   2.4)
>  _POSIX_SOURCE is defined by default with the value 200112L, so that the 
> XSI-compliant
>  version of strerror_r() is provided by default.

So how do we test for it?
The point is not whether or not we need this behavior but how to control it ... 
there's a simple ifdef required in one header ... what we are lacking is the 
knowledge of how we can best determine when we need it defined and when we 
don't.
Probably what's needed is some autoconf magic so that the configure script can 
detemine what needs doing and then common.h could use an autoconf generated 
value from config.h to decide what to do.
 ... any contribtion here welcome (I'm not great at autoconf).


reply via email to

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