Hi Alexandre,

> On Jan 28, 2015, Mike Stump <mikest...@comcast.net> wrote:
>
>> On Jan 28, 2015, at 2:27 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> 
>> wrote:
>>> There are two ways to fix this:
>>> 
>>> * Remove the definition of _XOPEN_SOURCE completely.  This is slightly
>>> more risky, but more future-proof since defining features test macros
>>> has been an endless source of trouble in the past.
>
>> I think I prefer this one...
>
>> But, as I say that, I read:
>
>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4372
>
>> and there is no hint what host caused him to put the change in, in the
>> first place.  :-( Alexandre, do you recall what host needed the
>> _XOPEN_SOURCE in libobjc for pthread_mutexattr_settype?
>
> The 2005 timeframe suggests it was probably GNU/Linux, and some digging
> in glibc indicates this flag affected nptl's pthread.h's declarations of
> various such functions back then.  This changed back in 2010, with glibc
> commit d3c7e68655, in response to newer standards, so I guess this
> confirms the suggestion from the timeframe.  Of course, this being a
> standard-compliance issue, other targets were likely affected as well,
> since it looks like there was a standards change, and removing the flag
> might cause regressions in old systems that remain stuck to the old
> standards.

Thanks for digging this up.  I doubt that anyone using a 2005 vintage
glibc is really using current GCC trunk, though ;-)

I recall that either or both of IRIX and Tru64 UNIX have been affected
by _XOPEN_SOURCE definitions in the past.  Both of them were last
supported in GCC 4.7, so are now ancient history.

I'm with Mike here: either we remove the _XOPEN_SOURCE definition now
and, in case of breakage, add them back exactly for those targets that
need it, documenting where and why it is necessary.  Otherwise, we will
never get rid of this cruft and break more modern systems on the way.

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to