| Message ID | yddpp9zjj49.fsf@lokon.CeBiTec.Uni-Bielefeld.DE |
|---|---|
| State | New |
| Headers | show |
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: 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? Anyway, going forward, I would say that any target that needs a specific value should just put in the #ifdef arch #define XPOPEN val #end, if they need it.
On Jan 28, 2015, Mike Stump <mikestump@comcast.net> 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: > 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.
Hi Alexandre, > On Jan 28, 2015, Mike Stump <mikestump@comcast.net> 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: > >> 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 <ro@CeBiTec.Uni-Bielefeld.DE> writes: > Hi Alexandre, > >> On Jan 28, 2015, Mike Stump <mikestump@comcast.net> 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: >> >>> 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. 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
On Feb 4, 2015, at 2:28 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes: >>> On Jan 28, 2015, Mike Stump <mikestump@comcast.net> wrote: >>>> On Jan 28, 2015, at 2:27 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >>>>> >>>>> * Remove the definition of _XOPEN_SOURCE completely. >>>> I think I prefer this one… >>>> and there is no hint what host caused him to put the change in >>> >>> The 2005 timeframe suggests it was probably GNU/Linux >> I'm with Mike here: either we remove the _XOPEN_SOURCE definition now > It's been a week now since I posted the patches and there's still no > conclusion which of the two alternatives to install. Well, my position is the removal of _XOPEN_SOURCE is the right patch. I’ve not seen any substantive disagreement. I’d post and test that patch. A build person, a libobjc person, a reasonably an affected target person or a global person can approve in my book. I’m not any of them… If Pinski is happy with my approving it, he can weigh in. I’d be happy to approve it.
On Wed, Feb 4, 2015 at 9:07 AM, Mike Stump <mikestump@comcast.net> wrote: > On Feb 4, 2015, at 2:28 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes: >>>> On Jan 28, 2015, Mike Stump <mikestump@comcast.net> wrote: >>>>> On Jan 28, 2015, at 2:27 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >>>>>> >>>>>> * Remove the definition of _XOPEN_SOURCE completely. > >>>>> I think I prefer this one… > >>>>> and there is no hint what host caused him to put the change in >>>> >>>> The 2005 timeframe suggests it was probably GNU/Linux > >>> I'm with Mike here: either we remove the _XOPEN_SOURCE definition now > >> It's been a week now since I posted the patches and there's still no >> conclusion which of the two alternatives to install. > > Well, my position is the removal of _XOPEN_SOURCE is the right patch. I’ve not seen any substantive disagreement. I’d post and test that patch. A build person, a libobjc person, a reasonably an affected target person or a global person can approve in my book. I’m not any of them… If Pinski is happy with my approving it, he can weigh in. I’d be happy to approve it. I am happy with which ever approach is decided as the safest and most portable. Thanks, Andrew Pinski
Hi Andrew, > On Wed, Feb 4, 2015 at 9:07 AM, Mike Stump <mikestump@comcast.net> wrote: >> On Feb 4, 2015, at 2:28 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >>> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes: >>>>> On Jan 28, 2015, Mike Stump <mikestump@comcast.net> wrote: >>>>>> On Jan 28, 2015, at 2:27 AM, Rainer Orth >>>>>> <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >>>>>>> >>>>>>> * Remove the definition of _XOPEN_SOURCE completely. >> >>>>>> I think I prefer this one… >> >>>>>> and there is no hint what host caused him to put the change in >>>>> >>>>> The 2005 timeframe suggests it was probably GNU/Linux >> >>>> I'm with Mike here: either we remove the _XOPEN_SOURCE definition now >> >>> It's been a week now since I posted the patches and there's still no >>> conclusion which of the two alternatives to install. >> >> Well, my position is the removal of _XOPEN_SOURCE is the right patch. >> I’ve not seen any substantive disagreement. I’d post and test that >> patch. A build person, a libobjc person, a reasonably an affected target >> person or a global person can approve in my book. I’m not any of them… >> If Pinski is happy with my approving it, he can weigh in. I’d be happy >> to approve it. > > > I am happy with which ever approach is decided as the safest and most portable. given that Mike and myself agree that removing _XOPEN_SOURCE completely and, should weird systems that need particular values resurface, define it only for those without breaking others, is the only safe and sane approach, I've installed that variant. Thanks. Rainer
# HG changeset patch # Parent 199ec7b54dc9c471def4ad9cc0452df842e5eff4 Fix failures on AIX (PR libobjc/63765) diff --git a/libobjc/thr.c b/libobjc/thr.c --- a/libobjc/thr.c +++ b/libobjc/thr.c @@ -28,8 +28,13 @@ see the files COPYING3 and COPYING.RUNTI /* The line below is needed for declarations of functions such as pthread_mutexattr_settype, without which gthr-posix.h may fail to compile within libobjc. While we only need XPG5 for this, Solaris - requires XPG6 for C99 and later. */ + requires XPG6 for C99 and later. We cannot use XPG6 unconditionally + since that breaks AIX. */ +#if defined __sun__ && defined __svr4__ #define _XOPEN_SOURCE 600 +#else +#define _XOPEN_SOURCE 500 +#endif #include "config.h" #include "tconfig.h" #include "coretypes.h"