This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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/ 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]