From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29956 invoked by alias); 7 May 2012 18:47:20 -0000 Received: (qmail 29940 invoked by uid 22791); 7 May 2012 18:47:19 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from toast.topped-with-meat.com (HELO topped-with-meat.com) (204.197.218.159) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 May 2012 18:47:06 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id 4E8D12C080; Mon, 7 May 2012 11:47:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "Carlos O'Donell" Cc: libc-ports@sourceware.org, libc-alpha@sourceware.org Subject: Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI. In-Reply-To: Carlos O'Donell's message of Saturday, 5 May 2012 17:52:06 -0400 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> Message-Id: <20120507184705.4E8D12C080@topped-with-meat.com> Date: Mon, 07 May 2012 18:47:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.0 cv=e8d9udV/ c=1 sm=1 a=p2DRgL-WZV4A:10 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=rKwxa7i4ziWomJhMfoMA:9 a=CjuIK1q_8ugA:10 a=WkljmVdYkabdwxfqvArNOQ==:117 X-IsSubscribed: yes 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/msg00030.txt.bz2 I trimmed the CC of people probably not very interested in arcane libc build internals, and added libc-alpha since we're now talking about possibly changing the generic build infrastructure. > Except that this idea doesn't work because the implicit rule uses > -undef and I didn't notice that. > > Therefore __ARM_PCS_VFP is *never* defined. I don't really recall, but I suspect that the reason for -undef may have been just the default predefines like "i386" or "linux" causing problems. Possibly there once was a principle that this mechanism should only be used for testing things we defined in config.h or other such places rather than predefines--the same general principle by which we prefer sysdeps file selection to #ifdef on predefines. But here we have a case where using the predefine seems sensible enough. There's no need to enforce such a philosophy mechanically so it constrains all cases. We can just do it socially through code review, to constrain reliance on predefines to the very few cases where we really think it's the wise choice. Just dropping -undef will break things by replacing all "linux" with "1" and so forth. In some trivial experiments on my random system version of GCC, -std=c99 or -std=c89 does not eliminate the nonstandard predefines (non-__ names), but -ansi does--despite the GCC manual's claim that -ansi is equivalent to -std=c89. So we could use -ansi instead of -undef, though that feels a little icky because it's so nonobvious (and contrary to documentation) that this is what has that effect. Conversely, I can see a doing a generalized version of configure-time tests for predefines. i.e. GLIBC_CHECK_PREDEFINE([__ARM_PCS_VFP]) would expand to a check that adds __ARM_PCS_VFP to an extra config.h-like file (or maybe just a config.make variable, for simplicity at the cost of full dependency tracking goodness) if predefined at configure time. Thanks, Roland