From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14061 invoked by alias); 6 May 2012 12:13:19 -0000 Received: (qmail 14051 invoked by uid 22791); 6 May 2012 12:13:18 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 06 May 2012 12:13:04 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1SR0Kj-0000z9-8x from joseph_myers@mentor.com ; Sun, 06 May 2012 05:13:01 -0700 Received: from digraph.polyomino.org.uk ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 May 2012 13:12:59 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.74) (envelope-from ) id 1SR0Ki-00025k-NG; Sun, 06 May 2012 12:13:00 +0000 Date: Sun, 06 May 2012 12:13:00 -0000 From: "Joseph S. Myers" To: Carlos O'Donell cc: Roland McGrath , Carlos O'Donell , Andrew Haley , libc-ports@sourceware.org, steve.mcintyre@linaro.org, michael.hope@linaro.org Subject: Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI. In-Reply-To: Message-ID: References: <4F886201.3040200@redhat.com> <4F886277.6000006@redhat.com> <20120413173512.5D52B2C074@topped-with-meat.com> <4F9515D5.60804@redhat.com> <4F99B990.7020300@mentor.com> <20120426220656.0CC302C0D3@topped-with-meat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00019.txt.bz2 On Sat, 5 May 2012, Carlos O'Donell wrote: > * Define HAVE_ARM_PCS_VFP in config.h.in Is there a way we can avoid architecture-specific defines needing to go in config.h.in - have architecture-specific files instead that it includes in some way? Does it work for configure.in fragments to use AC_CONFIG_HEADERS naming their own config.h.in fragments - will each fragment then get the right substitutions made on it? (A mechanism would also be needed for all the fragments to get included automatically - probably the main config.h should include all the others.) (The same issue applies with AC_SUBST as with AC_DEFINE - there shouldn't need to be a load of architecture-specific AC_SUBSTs in configure.in and config.make.in. But let's see if it can be solved for config.h.in first.) > To tell you the truth at this late hour I can't remember why we're > doing this in preconfigure, why can't this all be in > sysdeps/arm/configure.in where I can use AC_DEFINE? preconfigure is only relevant for choosing sysdeps directories. For defining something, sysdeps/arm/configure.in should work. -- Joseph S. Myers joseph@codesourcery.com