g++ cross distro compilation problem

Nick Stokes randomaccessiterator@gmail.com
Fri Jan 21 00:57:00 GMT 2011

On Thu, Jan 20, 2011 at 3:01 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 20 January 2011 19:57, Jonathan Wakely <jwakely.gcc@gmail.com> 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

More information about the Gcc-help mailing list