This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
El Wed, 4 Apr 2012 08:54:12 +0200
Jakub Jelinek <firstname.lastname@example.org> escribiÃ:
> 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).
Fedora at least plans to not support installing hfp and sfp on the same
system, while not completely decided I don't think we will be
supporting running 32 bit arm binaries on 64 bit arm. there is not
a legacy support use case that I can think of i.e. existing common
proprietary software. Though I imagine that we will use /lib64 for
consistency with existing 64 bit arches.