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. -- Joseph S. Myers jos...@codesourcery.com