From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31679 invoked by alias); 5 Apr 2012 16:16:26 -0000 Received: (qmail 31476 invoked by uid 22791); 5 Apr 2012 16:16:21 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cheddar.halon.org.uk (HELO cheddar.halon.org.uk) (217.10.144.130) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Apr 2012 16:16:09 +0000 Received: from bsmtp by cheddar.halon.org.uk with local-bsmtp (Exim 4.72) (envelope-from ) id 1SFpLt-0001kp-Qe; Thu, 05 Apr 2012 17:16:01 +0100 Received: from stemci01 by e102122-lin with local (Exim 4.76) (envelope-from ) id 1SFpLZ-0004ps-8r; Thu, 05 Apr 2012 17:15:41 +0100 Date: Thu, 05 Apr 2012 16:16:00 -0000 From: Steve McIntyre To: Mike Frysinger Cc: cross-distro@lists.linaro.org, Richard Earnshaw , "gcc-patches@gcc.gnu.org" , libc-ports@sourceware.org, "Joseph S. Myers" Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI Message-ID: <20120405161541.GX2880@linaro.org> References: <20120329193401.GA14860@dannf.org> <20120404070946.071e7c45@pegasus.ausil.us> <20120405163023.561469dca6619e31cf7a1d9e@linaro.org> <201204051108.58683.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204051108.58683.vapier@gentoo.org> X-attached: none User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00017.txt.bz2 On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote: >On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote: >> On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore wrote: >> > 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 >> >> One potential problem that is born from the /libhf suggestion is the >> danger of having a new top level directory (/libhf) with only one file, >> the dynamic linker. AFAIU it, no distro is currently willing to move away >> from its existing scheme (/lib) > >i don't think that's true. on an x86_64 system, the 64bit libs are in >/lib64/. some distros tried to (pointlessly imo) resist and force 64bits into >/lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy >imo, and afaik, they didn't break the ldso paths. > >so in a setup that only has hardfloat binaries, you'd have all the libs in >/libhf/, not just the ldso. > >> Loic suggested a -IMHO- better solution: to change the dynamic linker >> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular >> case). > >the implication in supporting both hardfloat and softfloat simultaneously is >that you'd could have them both installed. thus putting them both in /lib/ >doesn't make much sense if you're still going to need /libhf/ to hold >everything else. Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put them all in cleanly-separated paths corresponding to the triplets. I'm concerned that the potential proliferation of /lib* directories here could become very messy over time. I'm surprised that people seem to be happy to invent another namespace on a much more ad-hoc and arbitrary basis than the (mostly) well-understood triplets that we already have defined in the toolchains. Multi-arch is an attempt to make things cleaner for those of us that care about having lots of different platforms supported in parallel. Seen against that background, I was hoping that using the multi-arch path for the armhf linker would make sense. For people that don't care about multi-arch for themselves, a simple symbolic link is all that's needed. Cheers, -- Steve McIntyre steve.mcintyre@linaro.org Linaro.org | Open source software for ARM SoCs