On Thursday 05 April 2012 12:15:41 Steve McIntyre wrote:
On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote:
On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
Loic suggested a -IMHO- better solution: to change the dynamic linker filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular case).
the implication in supporting both hardfloat and softfloat simultaneously is that you'd could have them both installed. thus putting them both in /lib/ doesn't make much sense if you're still going to need /libhf/ to hold everything else.
Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put them all in cleanly-separated paths corresponding to the triplets.
/lib/ and /libhf/ is just as "clean" as /lib/ and /lib64/ (and now /libx32/). i see no difference here with a gcc configured for these multilib paths.
I'm concerned that the potential proliferation of /lib* directories here could become very messy over time. I'm surprised that people seem to be happy to invent another namespace on a much more ad-hoc and arbitrary basis than the (mostly) well-understood triplets that we already have defined in the toolchains.
the triplet situation isn't as clean as you imply here. there are already examples of not being able to tell the ABI based purely on that. mips64- linux-gnu could be n32 or n64. x86_64-linux-gnu could be x86_64 or x32.
the Debian multiarch project might have made up new triplets to account for this, but those don't translate exactly into the same triplet that are used for e.g. configure --host.
Multi-arch is an attempt to make things cleaner for those of us that care about having lots of different platforms supported in parallel. Seen against that background, I was hoping that using the multi-arch path for the armhf linker would make sense.
if you think that's a useful goal, then sure. but not everyone thinks the multiarch proposal is really all that useful. however, that (much larger) discussion is really out of scope here.
For people that don't care about multi-arch for themselves, a simple symbolic link is all that's needed.
i think it's safe to say that the wider community has yet to be convinced, so extending existing support via the existing standards makes more sense. -mike