On Thursday 05 April 2012 11:24:15 Konstantinos Margaritis wrote:
On Thu, 5 Apr 2012 11:08:56 -0400 Mike Frysinger wrote:
i don't think that's true. on an x86_64 system, the 64bit libs are in /lib64/. some distros tried to (pointlessly imo) resist and force 64bits into /lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy imo, and afaik, they didn't break the ldso paths.
so in a setup that only has hardfloat binaries, you'd have all the libs in /libhf/, not just the ldso.
That's exactly my concern. If /libhf is chosen for the dymamic linker path, but it's not adopted by everyone else for libraries and other files, then at best you'd have a symlink, at worst a dir with only one file inside.
if gcc declares libhf as another multilib target, then everyone else will get it automatically
note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or /libhf/ld-linux.so.[34]. /lib/<triplet>/<ldso> is really the only one i don't think doesn't belong.
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.
That case has only any chance of realization in a multiarch environment such as Debian/Ubuntu.
don't really know what you're talking about here. other distros have no problem with handling multilib. -mike