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