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

[Mike Frysinger]

On Thursday 05 April 2012 12:15:41 Steve McIntyre wrote:
> On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote:
> >On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
> >> Loic suggested a -IMHO- better solution: to change the dynamic linker
> >> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
> >> case).
> >
> >the implication in supporting both hardfloat and softfloat simultaneously
> >is that you'd could have them both installed.  thus putting them both in
> >/lib/ doesn't make much sense if you're still going to need /libhf/ to
> >hold everything else.
> 
> Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put
> them all in cleanly-separated paths corresponding to the triplets.

/lib/ and /libhf/ is just as "clean" as /lib/ and /lib64/ (and now /libx32/).  
i see no difference here with a gcc configured for these multilib paths.

> I'm concerned that the potential proliferation of /lib* directories
> here could become very messy over time. I'm surprised that people seem
> to be happy to invent another namespace on a much more ad-hoc and
> arbitrary basis than the (mostly) well-understood triplets that we
> already have defined in the toolchains.

the triplet situation isn't as clean as you imply here.  there are already 
examples of not being able to tell the ABI based purely on that.  mips64-
linux-gnu could be n32 or n64.  x86_64-linux-gnu could be x86_64 or x32.

the Debian multiarch project might have made up new triplets to account for 
this, but those don't translate exactly into the same triplet that are used 
for e.g. configure --host.

> Multi-arch is an attempt to make things cleaner for those of us that
> care about having lots of different platforms supported in
> parallel. Seen against that background, I was hoping that using the
> multi-arch path for the armhf linker would make sense.

if you think that's a useful goal, then sure.  but not everyone thinks the 
multiarch proposal is really all that useful.  however, that (much larger) 
discussion is really out of scope here.

> For people that don't care about multi-arch for themselves, a simple
> symbolic link is all that's needed.

i think it's safe to say that the wider community has yet to be convinced, so 
extending existing support via the existing standards makes more sense.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120405/8a587f88/attachment.sig>