Re: g++ cross distro compilation problem

[Nick Stokes <randomaccessiterator at gmail dot com>]

On Thu, Jan 20, 2011 at 7:57 PM, Nick Stokes
<randomaccessiterator@gmail.com> wrote:
> 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
>

I guess I can sweep under the rug for now by defining __USE_XOPEN2K8.
Incidentally, I need to make this transparent for users. Is it
possible to add such "custom" definitions to gcc at configure time (or
is there some other way to accomplish this)?

Thanks,
- Nick