From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27210 invoked by alias); 21 Jan 2011 02:03:52 -0000 Received: (qmail 27198 invoked by uid 22791); 21 Jan 2011 02:03:51 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iw0-f175.google.com (HELO mail-iw0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Jan 2011 02:03:45 +0000 Received: by iwn8 with SMTP id 8so1268752iwn.20 for ; Thu, 20 Jan 2011 18:03:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.13.138 with SMTP id c10mr38143iba.97.1295575423982; Thu, 20 Jan 2011 18:03:43 -0800 (PST) Received: by 10.231.152.143 with HTTP; Thu, 20 Jan 2011 18:03:43 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Jan 2011 02:03:00 -0000 Message-ID: Subject: Re: g++ cross distro compilation problem From: Nick Stokes To: Jonathan Wakely Cc: gcc-help@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg00321.txt.bz2 On Thu, Jan 20, 2011 at 7:57 PM, Nick Stokes wrote: > On Thu, Jan 20, 2011 at 3:01 PM, Jonathan Wakely = wrote: >> On 20 January 2011 19:57, Jonathan Wakely wrote: >>> On 20 January 2011 19:28, Nick Stokes wrote: >>>> >>>> Great! This indeed revealed it. =A0In /usr/include/locale.h (same >>>> location, line =A0133, in both distros actually) =A0there is #ifdef >>>> __USE_GNU =A0on CentOS version, which is =A0#ifdef __USE_XOPEN2K8 in >>>> SUSE's version. =A0 So, in fact if I define `__USE_XOPEN2K8' =A0while >>>> 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=3D200809L (or >>> greater) to enable __USE_XOPEN2K8. >> >> It looks as though you can also define _XOPEN_SOURCE=3D700 (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 =A0conditioned on > _XOPEN_SOURCE (or _POSIX_C_SOURCE) being defined. =A0 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