Armhf dynamic linker path
dennis at gilmore.net.au
Sat Mar 31 14:42:54 UTC 2012
On Sat, 31 Mar 2012 11:34:13 +0100
Steve McIntyre <steve.mcintyre at linaro.org> wrote:
> Hi folks,
> We really need to push on with getting the loader path for armhf
> standardised. The path that was agreed months ago is
> but clearly not everybody is using that yet. Dann has just posted an
> updated patch for gcc, and we want to get this reviewed / fixed up /
> accepted ASAP. Then we may need to backport it to older gcc releases.
> This is *important* so that we can help vendors release binaries that
> work on any hard-float distribution. For people who have made binaries
> that still use the old, broken location /lib/ld-linux.so.3, we can put
> symlinks in place *for now* but in the longer term as many distros
> switch to multi-arch the symlink is not an acceptable solution.
> I'm working on a more complete spec document for armhf to help us with
> this kind of thing, but it's not going as smoothly as I'd hoped and I
> don't want to wait for that as a blocker on the linker path.
I can say for Fedora that we have no plans to adopt that change. AFAIK
we never agreed to do so infact this is the first ive heard of it, we
have moved everything from /bin /lib /lib64 to under /usr in Fedora 17.
we do have symlinks to the original locations.
we use a host triplet of redhat-linux-gnu everywhere, we have special
handling in gcc and glibc to set it to redhat-linux-gnueabi for those
two builds we also set the arch portion to the target arch so it is
one of armv7hnl-redhat-linux-gnu or armv5tel-redhat-linux-gnu its done
that way to maintain compatability with all our other arches we use
armhfp as the base arch for floating point in Fedora. at this point
we support armv7hl as the base arch and armv7hnl as a sub arch for neon
optimised things though really neon iwmmx etc should all be run time
detectable. I really dont see the linker path being set as proposed as
working for us any time soon. its not to say that we cant change things
in the future. but its not been proposed or even thought of since
awareness at this point is nill.
I have no idea how linaro actually works or engages the community
because ive never seen it do so. I suggest if you really want to change
something on all distros you need to reach out and engage them. Im not
trying to inflame or otherwise start any kind of argument. Im want to
make sure we engage in a positive discussion. I really have no idea how
this was planned or where it was discussed or anything about it. If the
goal is to effect change within distros, the distros need to be fully
This needs to be a two way street. From my perspective there are many
things that need to be fixed to making supporting arm by distros scale
better, they are problems that need to be fixed at higher levels than
the distros. I will work to find where to engage people to get them
More information about the linaro-toolchain