g++ cross distro compilation problem

g++ cross distro compilation problem

[Nick Stokes]

Dear all:

I have very specific trouble with building GCC for our compute clusters.

Our setup is a fairly common compute cluster environment, where users
login to a front-end and compile their codes. Then they submit to a
batch queue to run them on  the compute nodes. This is not exactly a
cross compilation problem as the hardware on the compute nodes and the
login node are fairly similar (both x86_64). The particular GNU/Linux
distro on them, however, don't match (a fact we unfortunately can do
nothing about). The login node runs OpenSUSE 11.3, and the compute
nodes are CentOS 5.5. (and these are upgraded time and again)

The current distro versions of GCC (4.5.0 for login, and 4.1.2 for
computes) are incompatible and insufficient anyway since we need to
maintain multiple versions of GCC to address user needs. The idea was
to install all of 4.3, 4.4 and 4.5 versions on different prefixes
(/opt/gcc/4.3, /opt/gcc/4.4 and /opt/gcc/4.5, respectively) and NFS
mount these on the login node for users.

We stage the compilers, install, and test them on the compute nodes.
Everything seems ok. But on the login node the C++ compiler spits out
the following errors (for a simple hello world program):

$ g++ hello.cpp
In file included from
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/localefwd.h:42,
                 from
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/ios:42,
                 from
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/ostream:40,
                 from
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/iostream:40,
                 from main.cpp:1:
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:52:
error: 'uselocale' was not declared in this scope
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:52:
error: invalid type in declaration before ';' token
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:
In function 'int std::__convert_from_v(__locale_struct* const&, char*,
int, const char*, ...)':
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:72:
error: '__gnu_cxx::__uselocale' cannot be used as a function
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:97:
error: '__gnu_cxx::__uselocale' cannot be used as a function


I'd be very grateful for any help on identifying/fixing this problem.
More details follow. Thanks a million!!

- Nick

* C and Fortran compilers seem to work fine.
* The error is similar (identical except the version numbers) with
4.5.2 . I haven't tested other versions yet.
* The above failing compilation with the -v flag shows:

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/opt/gcc/4.4.3/
--with-mpfr=/opt/mpfr/2.4.2/gcc --with-gmp=/opt/gmp/4.3.2/gcc
--with-ppl=/opt/ppl/0.10.2/gcc --with-cloog=/opt/cloog/0.15.7/gcc
--disable-multilib --enable-languages=c,c++,fortran --disable-nls
Thread model: posix
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
 /opt/gcc/4.4.3/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/cc1plus
-quiet -v -iprefix
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/
-D_GNU_SOURCE main.cpp -quiet -dumpbase main.cpp -mtune=generic
-auxbase main -version -o /tmp/ccsQ5LGF.s
ignoring nonexistent directory
"/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/opt/gcc/4.4.3/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3"
ignoring duplicate directory
"/opt/gcc/4.4.3/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu"
ignoring duplicate directory
"/opt/gcc/4.4.3/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/backward"
ignoring duplicate directory
"/opt/gcc/4.4.3/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/include"
ignoring duplicate directory
"/opt/gcc/4.4.3/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/include-fixed"
ignoring nonexistent directory
"/opt/gcc/4.4.3/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3
 /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu
 /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/backward
 /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/include
 /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/include-fixed
 /usr/local/include
 /opt/gcc/4.4.3/bin/../lib/gcc/../../include
 /usr/include
End of search list.
GNU C++ (GCC) version 4.4.3 (x86_64-unknown-linux-gnu)
	compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d9a923d3ec89f59cc1ff5d5c3485c6c4
In file included from
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/localefwd.h:42,
                 from
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/ios:42,
                 from
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/ostream:40,
                 from
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/iostream:40,
                 from main.cpp:1:
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:52:
error: 'uselocale' was not declared in this scope
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:52:
error: invalid type in declaration before ';' token
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:
In function 'int std::__convert_from_v(__locale_struct* const&, char*,
int, const char*, ...)':
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:72:
error: '__gnu_cxx::__uselocale' cannot be used as a function
/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:97:
error: '__gnu_cxx::__uselocale' cannot be used as a function

Re: g++ cross distro compilation problem

[Ian Lance Taylor]

Nick Stokes <randomaccessiterator@gmail.com> writes:

> The current distro versions of GCC (4.5.0 for login, and 4.1.2 for
> computes) are incompatible and insufficient anyway since we need to
> maintain multiple versions of GCC to address user needs. The idea was
> to install all of 4.3, 4.4 and 4.5 versions on different prefixes
> (/opt/gcc/4.3, /opt/gcc/4.4 and /opt/gcc/4.5, respectively) and NFS
> mount these on the login node for users.
>
> We stage the compilers, install, and test them on the compute nodes.
> Everything seems ok. But on the login node the C++ compiler spits out
> the following errors (for a simple hello world program):

This must have something to do with the different versions of glibc
being used on the different machines.  I'm not sure what the exact
problem is, though.

Ian

Re: g++ cross distro compilation problem

[Jonathan Wakely]

On 19 January 2011 00:39, Nick Stokes  wrote:
>
> We stage the compilers, install, and test them on the compute nodes.
> Everything seems ok. But on the login node the C++ compiler spits out
> the following errors (for a simple hello world program):
>
> $ g++ hello.cpp
> In file included from
> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/localefwd.h:42,
>                 from
> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/ios:42,
>                 from
> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/ostream:40,
>                 from
> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/iostream:40,
>                 from main.cpp:1:
> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:52:
> error: 'uselocale' was not declared in this scope

This indicates that the compiler was built on a system which had the
necessary pieces for the C++ runtime library to be configured with
--enable-clocale=gnu (it will be used automatically if configure
detects it is supported)

Apparently on the system where it's installed something is missing.
Probably something in glibc, as Ian suggests.

Re: g++ cross distro compilation problem

[Jonathan Wakely]

On 19 January 2011 01:14, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 19 January 2011 00:39, Nick Stokes  wrote:
>>
>> We stage the compilers, install, and test them on the compute nodes.
>> Everything seems ok. But on the login node the C++ compiler spits out
>> the following errors (for a simple hello world program):
>>
>> $ g++ hello.cpp
>> In file included from
>> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/localefwd.h:42,
>>                 from
>> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/ios:42,
>>                 from
>> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/ostream:40,
>>                 from
>> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/iostream:40,
>>                 from main.cpp:1:
>> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:52:
>> error: 'uselocale' was not declared in this scope
>
> This indicates that the compiler was built on a system which had the
> necessary pieces for the C++ runtime library to be configured with
> --enable-clocale=gnu (it will be used automatically if configure
> detects it is supported)
>
> Apparently on the system where it's installed something is missing.
> Probably something in glibc, as Ian suggests.

I would try to build gcc on both systems, with the same options, and
compare the $TARGET/libstdc++-v3/config.log files to see what choice
of locale model is used.

I expect you'll find a difference.  You could force the basic model to
be used with --enable-clocale=generic, which should work the same
everywhere.  Ideally though you'd want to find out why the gnu model
doesn't work, and fix that.

Re: g++ cross distro compilation problem

[Nick Stokes]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

Hi Ian and Jonathan,

On Tue, Jan 18, 2011 at 8:17 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 19 January 2011 01:14, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 19 January 2011 00:39, Nick Stokes  wrote:
>>>
>>> [..]
>>
>> This indicates that the compiler was built on a system which had the
>> necessary pieces for the C++ runtime library to be configured with
>> --enable-clocale=gnu (it will be used automatically if configure
>> detects it is supported)
>>
>> Apparently on the system where it's installed something is missing.
>> Probably something in glibc, as Ian suggests.
>
> I would try to build gcc on both systems, with the same options, and
> compare the $TARGET/libstdc++-v3/config.log files to see what choice
> of locale model is used.
>
> I expect you'll find a difference.  You could force the basic model to
> be used with --enable-clocale=generic, which should work the same
> everywhere.  Ideally though you'd want to find out why the gnu model
> doesn't work, and fix that.
>

Ian,  you are right on. The versions are different:
compute node (where gcc is built):  /lib64/libc-2.5.so
login node (where gcc is used):  /lib64/libc-2.11.2.so

Jonathan, I looked at the config.logs (attached). Both seem to use gnu.

When I configure with --enable-clocale=generic it indeed remedies the
issue and g++ works without errors. Are the any serious implications
of not using gnu model? (any performance issues, or anything like that
sort?)

Thank you for all these prompt answers.

- Nick

[-- Attachment #2: config.centos.log.gz --]
[-- Type: application/x-gzip, Size: 21976 bytes --]

[-- Attachment #3: config.suse.log.gz --]
[-- Type: application/x-gzip, Size: 22101 bytes --]

Re: g++ cross distro compilation problem

[Jonathan Wakely]

On 19 January 2011 23:27, Nick Stokes wrote:
>
> Ian,  you are right on. The versions are different:
> compute node (where gcc is built):  /lib64/libc-2.5.so
> login node (where gcc is used):  /lib64/libc-2.11.2.so
>
> Jonathan, I looked at the config.logs (attached). Both seem to use gnu.

Yes, both your distros have a new enough glibc, so the problem might be simpler:
does it make any difference if you define _GNU_SOURCE when compiling?

That should ensure uselocale is defined by <locale.h>

> When I configure with --enable-clocale=generic it indeed remedies the
> issue and g++ works without errors. Are the any serious implications
> of not using gnu model? (any performance issues, or anything like that
> sort?)

The GNU model, which requires glibc 2.3 or later, supports a
per-thread locale (via the uselocale function) so that the locale can
be changed temporarily by the C++ runtime library without affecting
the global process-wide locale.  I believe this avoids possible race
conditions in multithreaded programs which make use of locales.

Re: g++ cross distro compilation problem

[Nick Stokes]

On Wed, Jan 19, 2011 at 7:47 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 19 January 2011 23:27, Nick Stokes wrote:
>>
>> Ian,  you are right on. The versions are different:
>> compute node (where gcc is built):  /lib64/libc-2.5.so
>> login node (where gcc is used):  /lib64/libc-2.11.2.so
>>
>> Jonathan, I looked at the config.logs (attached). Both seem to use gnu.
>
> Yes, both your distros have a new enough glibc, so the problem might be simpler:
> does it make any difference if you define _GNU_SOURCE when compiling?
>

Assuming you are referring to compiling a code with g++  (and not
compiling gcc itself), then no it doesn't make a difference. (in fact,
g++ -v shows that _GNU_SOURCE is already defined).

Could it be some other silly mistake on my part, e.g forgetting to set
an environment variable or something? Indeed there is the distro's g++
compiler installed on the login node, and most of these headers --
that are potentially incompatible with the gcc versions I am trying to
install under /opt -- are under common places  /usr/include etc.

>
> The GNU model, which requires glibc 2.3 or later, supports a
> per-thread locale (via the uselocale function) so that the locale can
> be changed temporarily by the C++ runtime library without affecting
> the global process-wide locale.  I believe this avoids possible race
> conditions in multithreaded programs which make use of locales.
>

I see. Thanks for this info, it seems I should not be using generic
locale then.


- Nick

Re: g++ cross distro compilation problem

[Jonathan Wakely]

On 20 January 2011 15:53, Nick Stokes wrote:
>
> Assuming you are referring to compiling a code with g++  (and not

Yep, that's what I meant.

> compiling gcc itself), then no it doesn't make a difference. (in fact,
> g++ -v shows that _GNU_SOURCE is already defined).
>
> Could it be some other silly mistake on my part, e.g forgetting to set
> an environment variable or something? Indeed there is the distro's g++
> compiler installed on the login node, and most of these headers --
> that are potentially incompatible with the gcc versions I am trying to
> install under /opt -- are under common places  /usr/include etc.

You don't need to set any environment variables to use GCC, the 4.4.3
compiler under /opt will find its own c++ headers not the ones in
/usr/include/c++/x.y.z (you can check the paths printed with -v to see
that for yourself)

You need to find why uselocale is not defined here:

/opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:52:
error: 'uselocale' was not declared in this scope

Try using the -E flag and examining the preprocessed output. Do that
on both machines and look for differences in the path or contents of
the locale.h header.  To minimise the output it should be sufficient
to do:

echo '#include <ios>' | g++ -E -x c++  -

Re: g++ cross distro compilation problem

[Nick Stokes]

On Thu, Jan 20, 2011 at 11:40 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 20 January 2011 15:53, Nick Stokes wrote:
>>
>> Assuming you are referring to compiling a code with g++  (and not
>
> Yep, that's what I meant.
>
>> compiling gcc itself), then no it doesn't make a difference. (in fact,
>> g++ -v shows that _GNU_SOURCE is already defined).
>>
>> Could it be some other silly mistake on my part, e.g forgetting to set
>> an environment variable or something? Indeed there is the distro's g++
>> compiler installed on the login node, and most of these headers --
>> that are potentially incompatible with the gcc versions I am trying to
>> install under /opt -- are under common places  /usr/include etc.
>
> You don't need to set any environment variables to use GCC, the 4.4.3
> compiler under /opt will find its own c++ headers not the ones in
> /usr/include/c++/x.y.z (you can check the paths printed with -v to see
> that for yourself)
>
> You need to find why uselocale is not defined here:
>
> /opt/gcc/4.4.3/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu/bits/c++locale.h:52:
> error: 'uselocale' was not declared in this scope
>
> Try using the -E flag and examining the preprocessed output. Do that
> on both machines and look for differences in the path or contents of
> the locale.h header.  To minimise the output it should be sufficient
> to do:
>
> echo '#include <ios>' | g++ -E -x c++  -
>

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?

Thanks!!

Re: g++ cross distro compilation problem

[Jonathan Wakely]

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.

Re: g++ cross distro compilation problem

[Jonathan Wakely]

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.

Re: g++ cross distro compilation problem

[Nick Stokes]

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

Re: g++ cross distro compilation problem

[Nick Stokes]

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

Re: g++ cross distro compilation problem

[Jonathan Wakely]

On 21 January 2011 02:03, Nick Stokes wrote:
>>
>> 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.

By "GCC features.h header" do you mean one under the GCC installation
tree in /opt, or /usr/include/features.h?  If the former, that
explains the problem - you have a fixinclude'd features.h created on
the old system, which has a glibc that predates POSIX 2008, so
_GNU_SOURCE doesn't define __USE_XOPEN2K8 (as I think it would on a
newer glibc)

> 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)?

http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

Or you can provide a wrapper script which invokes the actual gcc
driver with the additional flags you need.

Rather than defining __USE_XOPEN2K8 (which is definitely not meant to
be defined/undefined by users) I would consider modifying the
features.h file so that _GNU_SOURCE sets __XOPEN28K.  You could try
building the same GCC on a login machine, and compare the features.h
from that build (if it has one, otherwise just use
/usr/include/features.h)

Re: g++ cross distro compilation problem

[Nick Stokes]

On Fri, Jan 21, 2011 at 4:16 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 21 January 2011 02:03, Nick Stokes wrote:
>>>
>>> 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.
>
> By "GCC features.h header" do you mean one under the GCC installation
> tree in /opt, or /usr/include/features.h?  If the former, that
> explains the problem - you have a fixinclude'd features.h created on
> the old system, which has a glibc that predates POSIX 2008, so
> _GNU_SOURCE doesn't define __USE_XOPEN2K8 (as I think it would on a
> newer glibc)
>


Yes, exactly. CentOS isn't really "cutting edge" in updates..


>> 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)?
>
> http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
>
> Or you can provide a wrapper script which invokes the actual gcc
> driver with the additional flags you need.
>
> Rather than defining __USE_XOPEN2K8 (which is definitely not meant to
> be defined/undefined by users) I would consider modifying the
> features.h file so that _GNU_SOURCE sets __XOPEN28K.  You could try
> building the same GCC on a login machine, and compare the features.h
> from that build (if it has one, otherwise just use
> /usr/include/features.h)
>

This sounds best.

Thanks a lot Jonathan!