Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jakub Jelinek <jakub at redhat dot com>]

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, 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).

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).

	Jakub