Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 6 Nov 2014 18:34:00 +0100
From: Wermut <>
To: "" <>
Subject: Re: What does dir in arch/<dir> mean in musl?

There are at least two different ldconfig like scripts for musl found
in Alpine Linux and Debian that you can possibly take for reference.

Alpine Linux:


On Thu, Nov 6, 2014 at 4:38 PM, Rich Felker <> wrote:
> 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
>> <paths>
>> EOF
>> where LDSO_ARCH is defined in arch/<dir>/reloc.h.  But what does
>> <dir> 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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.