On 4 April 2012 18:54, Jakub Jelinek jakub@redhat.com wrote:
On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be "good to have" to be able to run binaries for either without resorting to a chroot, and only testing purposes.
Bumping major or calling it ld-linux-foo.so.3 is out of question?
I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part.
If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc
OK. This gives a different path for the hard float loader and lets the Debian guys add on top of that. I'll ping them and see what they think.
and for those that choose the Debian layout instead, if it is added somehow configurable into upstream gcc/glibc of course handle it similarly there.
Agreed.
I just wonder why that hasn't been done 10 years ago and only needs doing now
FPUs have only become common on ARM in the last few years. softfp was a good interim work around but performance is significantly better with hard float.
(of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
Yip. I assume something like /lib64 to stay consistent with other architectures. aarch64 is hard float only.
-- Michael