Re: What does dir in arch/<dir> mean in musl?

[Wermut <wermut@gmail.com>]

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: http://git.alpinelinux.org/cgit/aports/tree/main/musl/ldconfig

Debian: https://github.com/wermut/musl/blob/master/debian/scripts/ld-musl-config


On Thu, Nov 6, 2014 at 4:38 PM, Rich Felker <dalias@libc.org> 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