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

Jeff Law law@redhat.com
Tue Apr 10 06:17:00 GMT 2012


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



More information about the Gcc-patches mailing list