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

2012-04-09 Thread Adam Conrad
 a canonical location and
can resolve that, that's fine.  I will still (obviously, I think, from
my comments above) argue that the linker should live in a guaranteed
unique location.  Overlap with other arches in /lib64 is certainly far
more likely than overlap in /libhf.

... Adam Conrad



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

2012-04-09 Thread Adam Conrad
On Mon, Apr 09, 2012 at 07:14:45PM -0400, Mike Frysinger wrote:
> 
> again, saying "/lib//" isn't multiarch is bunk.  but it sounds 
> like you're fine with /libhf/, so there isn't anything left to thrash about 
> there.

I appreciate your careful reading of my email and the issues I outlined,
and I look forward to your new urbandictionary definition of the common
colloquialism "fine with".

A path for one file isn't multi-arch.  A unique path for linkers does help
facilitate multi-arch, but we're not forcing you to put libraries some
place you don't want to, implement new ideas you don't want to, or any
other such "bunk", as you so obviously impartially put it.

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.

This isn't about pushing multi-arch on others.  This isn't about pushing
multi-arch on others.  Also, this.  Isn't.  About.  Pushing.  Multi-arch.
On.  Others.  I don't know how much more clear I can make that.

If the QT guys filed a bug/feature request on libstdc++ asking to change
something that didn't break C++ standards, but facilitated some fancy
thing they were working on, my response wouldn't be "dude, I use GTK,
what do I care about your weird needs, screw you and your QT agenda", it
would be to ask them why they need the thing they need, evaluate how, if
in any way, that would impact other users, and work with them.

Using unique linker paths (for new architectures) hurts exactly zero
users, and this discussion has taken up FAR MORE developer time than
implementation ever would have.  Arguing against unique linker paths for
the reason that "we've never done that before" is not helpful, and it's
blatantly ignoring technical arguments and hiding them behind some bizarre
inter-distro conspiracy theory.

Maybe the conspiracy theory is fun for you.  I don't know.  It's not for
me.  We were told by GCC upstream that we needed distro consensus.  We
got that over half a year ago.  Now I'm told by distros that the patch
not being upstream is why they are backing out of said consensus.  Fun.

 Adam Conrad


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

2012-04-09 Thread Adam Conrad
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?

Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for
us right now, due to sheer luck, and you're running with that as saying
that we clearly have no problem here worth solving.  When the next
architecture clashes with linkers on another (hint: it almost certainly
will), do we get to argue about this all over again in six months,
instead of codifying a new and saner practice now?

... Adam Conrad