On Thu, Jan 20, 2011 at 3:01 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 20 January 2011 19:57, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >> On 20 January 2011 19:28, Nick Stokes wrote: >>> >>> Great! This indeed revealed it. In /usr/include/locale.h (same >>> location, line 133, in both distros actually) there is #ifdef >>> __USE_GNU on CentOS version, which is #ifdef __USE_XOPEN2K8 in >>> SUSE's version. So, in fact if I define `__USE_XOPEN2K8' while >>> compiling on SUSE, it works. Hmm, go figure.. This can not be the >>> right way to do this. What am I missing? >> >> I don't know why they're different (on my glibc 2.12 system the >> uselocale definition is guarded by __USE_GNU, just like your CentOS >> system) but it looks like you've found the solution. >> >> Users are not supposed to use the __USE_XXX macros, instead you should >> define _GNU_SOURCE to enable __USE_GNU and _POSIX_C_SOURCE=200809L (or >> greater) to enable __USE_XOPEN2K8. > > It looks as though you can also define _XOPEN_SOURCE=700 (or greater) > to set __USE_XOPEN2K8 > > Either way, you should use one of those standard feature test macros, > not the __USE_XOPEN2K8 one which is an internal implementation > details, see man feature_test_macros for more details. > Thanks, these are great leads! But unfortunately this didn't work either. The reason is subtle (and elusive!): On CentOS (where gcc is built) the GCC features.h header is defining __USE_XOPEN2K, and not __USE_XOPEN2K8 conditioned on _XOPEN_SOURCE (or _POSIX_C_SOURCE) being defined. But on the front-end SUSE, the /usr/include/locale.h is expecting __USE_XOPEN2K8, hence fails. - nick
