This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libobjc] Fix failures on AIX (PR libobjc/63765)

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> Hi Alexandre,
>> On Jan 28, 2015, Mike Stump <> wrote:
>>> On Jan 28, 2015, at 2:27 AM, Rainer Orth <ro@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:
>>> 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.

It's been a week now since I posted the patches and there's still no
conclusion which of the two alternatives to install.


Rainer Orth, Center for Biotechnology, Bielefeld University

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]