On 04/09/2012 11:17 PM, Adam Conrad wrote:
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 what you haven't done is make a case for why anyone should care
about this problem.
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?
My understanding of that architecture is that it's being handled as
completely different from it's prior implementations. ie, the toolchain
and other things are treating it as an entirely separate architecture
even though there is some common lineage to prior implementations.
If the tools are treating this upcoming architecture as a separate and
distinct architecture rather than as a variant of a prior architecture,
then why do we have to worry about conflicting in the filesystem space?
And just to be clear, I'm not taking sides, merely pointing out that you
haven't made the case in this forum in a way that folks understand why
this is an important problem.
Jeff
