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

[Jakub Jelinek]

On Tue, Apr 10, 2012 at 05:17:36AM +0000, Adam Conrad wrote:
> On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote:
> > On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
> > > I realize that most people can't see past their own use case to understand
> > > why a unique location for linkers is helpful, useful, and important for
> > > some other people's use cases, but you either didn't read or chose to
> > > ignore why using multilib paths just plain doesn't scale past a single
> > > base architecture, and why that's a problem for people who aren't you.
> > 
> > and as already stated, the proposed paths here, free of multiarch subpaths, 
> > satisfy the requirements that you've put forth
> 
> Like I said, then, you didn't actually read or understand why proposing
> multilib paths doesn't work.  You realize conceptually, I hope, that
> there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once
> you cross the base CPU architecture boundary, right?

But you are incorrectly assuming that anyone outside Debian actually sees
that as a problem.  When we've designed multilib for Linux (following Irix
layout, which for some weird reason Debian was the only one which ignored
it), it hasn't been a goal and I don't see why it should be a goal now.
For crossing base CPU architecture boundaries we have for many years
--sysroot, you can't run natively the binaries/libraries anyway, while
for ABIs that you can run natively it is very common to run binaries for the
different native ABIs concurrently.

We really want consistency about the dynamic linker names etc. across
different targets and sneaking silently multiarch paths on one architecture
would make it inconsistent with all the others.  So, please just use
/libhf/ld-linux.so.3.

> will), do we get to argue about this all over again in six months,
> instead of codifying a new and saner practice now?

Not everybody agrees it is a saner practice.

	Jakub