From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11297 invoked by alias); 3 Apr 2012 22:56:37 -0000 Received: (qmail 11287 invoked by uid 22791); 3 Apr 2012 22:56:35 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_BH,TW_IB 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; Tue, 03 Apr 2012 22:56:22 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1SFCeC-00036z-BL from joseph_myers@mentor.com ; Tue, 03 Apr 2012 15:56:20 -0700 Received: from digraph.polyomino.org.uk ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2012 23:56:18 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.74) (envelope-from ) id 1SFCeA-0004WM-1e; Tue, 03 Apr 2012 22:56:18 +0000 Date: Tue, 03 Apr 2012 22:56:00 -0000 From: "Joseph S. Myers" To: Michael Hope cc: dann frazier , Richard Earnshaw , "cross-distro@lists.linaro.org" , "gcc-patches@gcc.gnu.org" , libc-ports@sourceware.org Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI In-Reply-To: Message-ID: References: <20120329193401.GA14860@dannf.org> <4F75F2E2.3030909@arm.com> <20120402210653.GC28152@dannf.org> 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-04/txt/msg00000.txt.bz2 On Tue, 3 Apr 2012, Michael Hope wrote: > +#define GLIBC_DYNAMIC_LINKER \ > + "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \ > + %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \ > + %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}" (a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to be handled in specs. (b) You need to handle compilers configured with --with-float=hard, so make the specs depend on the default ABI the compiler was configured with. (c) Please include libc-ports on future submissions and provide both the GCC patch and the glibc ports patch that have been tested to work together to build and install the library in the given path; a patch to one component like this cannot sensibly be considered in isolation. I imagine you'll need appropriate ARM preconfigure support to detect what ABI the compiler is using, much like the support for MIPS, so that the right shlib-versions files are used. I try to follow all ARM glibc discussions on libc-ports closely, as the ARM glibc maintainer; was there a previous discussion of the dynamic linker naming issue there that I missed? (The only previous relevant discussion that I recall is one on patches@eglibc.org starting at , regarding how the dynamic linker should check that a library has the right ABI, and there was no real followup on that after I indicated what would seem to be the appropriate implementation approaches and places for subsequent discussion.) I have no idea whether shlib-versions files naming a file in a subdirectory will work - but if not, you'd need to send a patch to libc-alpha to support dynamic linkers in subdirectories, with appropriate justification for why you are doing something different from all other architectures. (d) Existing practice for Power Architecture and MIPS at least is that hard-float and soft-float *don't* use different library directories / dynamic linkers. (e) Existing practice for cases that do use different dynamic linkers is to use a separate library directory, not just dynamic linker name, as in lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to make two sets of libraries work in parallel if you have separate library directories like that. So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to handle that directory, I think), and these different Debian-style names could be implemented separately in a multiarch patch if someone submits one that properly accounts for my review comments on previous patch versions (failure to produce such a fixed patch being why Debian multiarch directory support has not got into GCC so far). -- Joseph S. Myers joseph@codesourcery.com