From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31102 invoked by alias); 21 Jan 2011 09:16:44 -0000 Received: (qmail 31093 invoked by uid 22791); 21 Jan 2011 09:16:43 -0000 X-SWARE-Spam-Status: No, hits=-2.2 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-iy0-f175.google.com (HELO mail-iy0-f175.google.com) (209.85.210.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Jan 2011 09:16:28 +0000 Received: by iyj18 with SMTP id 18so1528707iyj.20 for ; Fri, 21 Jan 2011 01:16:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.170.138 with SMTP id f10mr422639icz.269.1295601387223; Fri, 21 Jan 2011 01:16:27 -0800 (PST) Received: by 10.42.230.66 with HTTP; Fri, 21 Jan 2011 01:16:27 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Jan 2011 09:16:00 -0000 Message-ID: Subject: Re: g++ cross distro compilation problem From: Jonathan Wakely To: Nick Stokes 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/msg00322.txt.bz2 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 =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. 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)