On Wed, 4 Apr 2012, Jakub Jelinek wrote:
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, 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. I just wonder why that hasn't been done 10 years ago and only needs doing now (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
Exactly. The default should follow the existing practice for other architectures.
One needs to wonder also why arm hasn't switched to 128-bit long double when all other mainstream architectures did (I hope at least aarch64 will use it by default).
The AArch64 ABI (generic, not GNU/Linux, and draft, still subject to incompatible change) is public and used 128-bit long double the last time I checked.
My presumption is that there has been no demand for long double wider than double among 32-bit ARM users.