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
signature.asc
Description: This is a digitally signed message part.
