From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6459 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: What does dir in arch/ mean in musl? Date: Thu, 6 Nov 2014 10:38:59 -0500 Message-ID: <20141106153859.GA22465@brightrain.aerifal.cx> References: <545B6BDD.2030200@opensource.dyc.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1415288361 6258 80.91.229.3 (6 Nov 2014 15:39:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2014 15:39:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6472-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 06 16:39:15 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XmP9V-0002vU-Kv for gllmg-musl@m.gmane.org; Thu, 06 Nov 2014 16:39:13 +0100 Original-Received: (qmail 5651 invoked by uid 550); 6 Nov 2014 15:39:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5643 invoked from network); 6 Nov 2014 15:39:11 -0000 Content-Disposition: inline In-Reply-To: <545B6BDD.2030200@opensource.dyc.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6459 Archived-At: On Thu, Nov 06, 2014 at 07:38:53AM -0500, Anthony G. Basile wrote: > Hi everyone, > > In the context of integrating musl with gentoo, we have to deal with > how we construct the link path file. So far we've been doing a > variation of > > LDSO_ARCH=$(basename /lib/ld-musl-*.so.1) > cat << EOF > /etc/${LDSO_ARCH%so.1}path > > EOF > > > where LDSO_ARCH is defined in arch//reloc.h. But what does > mean in this case? I know it *says* arch but it doesn't > appear to be arches but rather an inconsistent combination of ISA + > ABI. Eg. x32 is an ABI which runs on 64-bit intel ISA, while x86_64 > is a different ABI on the same. On the other hand all mips > isas/abis/endians/floats are under arch/mips. This is an area where existing practice differs a lot. For the kernel folks, even 32- and 64-bit versions of a particular ISA are considered the same arch. musl is on the opposite end of the spectrum, where basic arch divisions cover both the ISA and how it's being used (you can think of this as ABI). Here, x32 and x86_64 are separate archs, as are powerpc/powerpc64, mips/mipsn32/mips64, etc. (the latter are not yet supported though). musl also has subarchs for minor variants; these should be considered an implementation detail. Examples are armhf, mips-sf, mipsel, and so on. From your perspective, they're distinct archs; the distinction between archs and subarchs is really purely an implementation detail of musl's headers and build system. If you don't want to hard-code a list of arch names, the easiest way to get the right one would be to compile a dynamic linked program and use readelf or objdump to read the PT_INTERP (dynamic linker) header. The method you showed above will fail if more than one dynamic linker is installed, which could easily be the case if the user is running binaries for multiple ABI variants on a given piece of hardware or using qemu to run foreign binaries. The method I described necessarily tells you the one connected to the compiler you're using. Rich