From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18572 invoked by alias); 4 Apr 2012 12:10:33 -0000 Received: (qmail 18545 invoked by uid 22791); 4 Apr 2012 12:10:25 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_00,KHOP_THREADED,SARE_RMML_Stock10,TW_BH,TW_IB X-Spam-Check-By: sourceware.org Received: from mail.ausil.us (HELO mail.ausil.us) (74.119.218.133) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Apr 2012 12:09:53 +0000 Received: from localhost (unknown [127.0.0.1]) by mail.ausil.us (Postfix) with ESMTP id 400926480F6; Wed, 4 Apr 2012 13:47:30 +0000 (UTC) Received: from mail.ausil.us ([127.0.0.1]) by localhost (mail.ausil.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H39WXr9iVqBC; Wed, 4 Apr 2012 13:47:29 +0000 (UTC) Received: from pegasus.ausil.us (osiris.ausil.us [75.149.73.105]) by mail.ausil.us (Postfix) with ESMTP id 0F6EE6480E2; Wed, 4 Apr 2012 13:47:29 +0000 (UTC) Date: Wed, 04 Apr 2012 12:10:00 -0000 From: Dennis Gilmore To: "Joseph S. Myers" Cc: Michael Hope , libc-ports@sourceware.org, "gcc-patches@gcc.gnu.org" , Richard Earnshaw , "cross-distro@lists.linaro.org" Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI Message-ID: <20120404070946.071e7c45@pegasus.ausil.us> In-Reply-To: References: <20120329193401.GA14860@dannf.org> <4F75F2E2.3030909@arm.com> <20120402210653.GC28152@dannf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00194.txt.bz2 On Wed, 4 Apr 2012 09:06:05 +0000 (UTC) "Joseph S. Myers" wrote: > On Wed, 4 Apr 2012, Michael Hope wrote: > > > The tricky one is new GCC with old GLIBC. GCC may have to do a > > configure time test and fall back to /lib/ld-linux.so.3 if the hard > > float loader is missing. > > I don't think that's appropriate for ABI issues. If a different > dynamic linker name is specified, GCC should use it unconditionally > (and require new enough glibc or a glibc installation that was > appropriately rearranged). > > > > 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. > > > > Understood. For now this is just a path. There's more > > infrastructure work needed if the path includes a directory. > > Formally it's just a path - but an important feature of GNU/Linux and > the GNU toolchain is consistency between different architectures and > existing upstream practice is that the dynamic linker is always in > the same directory as the other associated libraries and that this > has the form /lib. In the absence of a compelling reason, > which I have not seen stated, to do otherwise for a single case, I > think that existing practice should be followed with the dynamic > linker being in a directory such as /libhf. Consistency across architectures is why Fedora does many of the things the way it does, It really doesn't make much sense to me to diverge from that. > The "more infrastructure work needed" makes clear that you need > libc-alpha buy-in *before* putting any patches into GCC or ports. > But maybe if you don't try to put the dynamic linker in a different > directory from the other libraries, it's easier to support via > existing mechanisms (setting slibdir differently if > --enable-multiarch-directories or similar)? > > > Do the MIPS or PowerPC loaders detect the ABI and change the library > > path based on that? I couldn't tell from the code. > > No, they don't detect the ABI. Both ABIs (and, for Power, the e500v1 > and e500v2 variants - compatible with soft-float at the > function-calling level but with some glibc ABI differences with > soft-float and with each other) use the same directories. > > > > (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. > > > > Is this required, or should it be left to the distro to choose? > > Once the loader is in control then it can account for any distro > > specific features, which may be the standard /lib and /usr/lib for > > single ABI distros like Fedora or /usr/lib/$tuple for multiarch > > distros like Ubuntu and Debian. > > I thought Fedora used the standard upstream /lib64 on x86_64 and so > would naturally use a standard upstream /libhf where appropriate. Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but wouldn't object to /libhf though today we have f17 about to go beta and all of rawhide built using /lib Fedora also has software floating point being installed into /lib also > > > 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) Dennis