Sorry. Missed a major point. _GNU_SOURCE is transformed into multiple other defines in features.h in glibc.
#ifdef _GNU_SOURCE # define __USE_GNU 1 #endif Our sys/features.h does not have the comparable ifdef. We are likely missing others as it turns on about ten other feature flags in the glibc features.h. I guess we need to follow this pattern and add _GNU_SOURCE to our sys/features.h. The others need another round of thought. --joel On 11/12/2013 1:02 PM, Joel Sherrill wrote: > On 11/12/2013 12:32 PM, Sebastian Huber wrote: >> On 11/12/2013 03:11 PM, Joel Sherrill wrote: >>> On 11/12/2013 2:27 AM, Sebastian Huber wrote: >>>>> On 2013-11-11 21:30, Jennifer Averett wrote: >>>>>>> @@ -206,6 +206,24 @@ >>>>>>> int _EXFUN(pthread_attr_setguardsize, >>>>>>> (pthread_attr_t *__attr, size_t __guardsize)); >>>>>>> >>>>>>> +#if defined(__USE_GNU) && defined(__rtems__) >>>>>>> +/* POSIX thread APIs beyond the POSIX standard but provided in RTEMS >>>>>>> + * for compatibility with GNU/Linux. >>>>>>> + */ >>>>> >>>>> Who is supposed to define this __USE_GNU? >>>>> >>> The application or implementation before including >>> the header files. This is common practice and how >>> it is done in /usr/include/pthread.h on GNU/Linux. >>> >>> http://man7.org/linux/man-pages/man3/pthread_attr_setaffinity_np.3.html >>> >>> There are also other constants like thus __USE_XOPEN2K, __USE_BSD, >>> and __USE_XOPEN2K8 are pretty common. It is similar to the STDC >>> one but that's usually tripped by gcc, while these are application >>> choices on what library API standard to adhere to. >>> >>> Sorry to sound pendantic but this is the common practice. >> >> Yes, exactly this is why I asked. In the man page you have: >> >> *#define _GNU_SOURCE */* See feature_test_macros(7) */ >> *#include <pthread.h>* >> >> You use __USE_GNU. >> > > /usr/include/pthread.h on Linux has __USE_GNU. I don't > see a _USE_GNU in the .h files. > > feature_test_macros(7) uses all _ versions. > > I would guess the std C version is adding it. > > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
