+++ Mike Frysinger [2012-04-05 13:37 -0400]: > 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.
Quite true, but that's viewing the world from a place where /lib /lib64 was the right answer. It's a very limited version of multiarch which only allows for the co-installability of 2 ABIs. /lib64 doesn't let us co-install arm64(aarch64) and amd64, for example (which is imminently going to be a very reasonable thing to want to do). The limitation starts to show when you consider x32 and armhf so we get 4 top-level library names to deal with it: /lib /lib64 /libhf and /libx32, but that still only allows certain combinations of architectures/ABIs. The point about using the triplet(or something very similar) to distinguish things is that it is generic - any combination you care to mention will work. Now you are right that it doesn't really matter for just the linker path. We can arrange to ensure that they don't clash in various ways, as discussed on this thread. But there is a reasonable expectation that the linker lives in the same library directory as the other libraries, and we can only arrange for that to work if every architecture/ABI has it's own directory. Which is why using triplets (or something very similar) makes so much sense. Yes, it's a break with the /lib /lib64 convention, but it seems fairly clear to me that that is reaching the end of it's life and inventing this new top-level libfoo set that doesn't even solve the problem in the general case, isn't a good solution. /lib/<triplet>/ was proposed for armhf and aarch64 in an attempt to get these architectures 'right' from the get-go, not to have to use symlinks. It seems ironic if the outcome of the attempt to have a sensible namespace for these new ABIs from the start, is actually some other completely arbitrary namespace which is a much worse solution technically. I'm really surprised anyone would think that was a good choice, after thinking about the issue for a while. I realise this way of thinking is a big break with recent tradition. I thought it was madness when I first came across it too, but if you step back and think about the wider problem for a while I hope you can see that this actually makes a great deal of sense. Clearly those of us that have been thinking about this for some time have failed to include the glibc people in debates to date, and that is a massive cock-up, for which I apologise wholeheartedly. I don't really know how that happened, we really did spend quite a lot of time trying to be inclusive, because, well, that's the right thing to do. I guess it just shows how siloed distro development is, and thus why the cross-distro list is a very welcome development. > > 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. Yes, but that's OK so long as those pairs are ABI-compatible, you can freely mix n32 and n64 mips libraries. If you can't do that for x86_64 and x32 libraries, but they have the same triplet, that seems like a bad plan. > 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. No, not exactly, which is why we originally had a similar-but-different set of tuples to describe the namespace, but after a lot of discussion and feedback decided that GNU triplets were good-enough, especially if we avoided incompatible use in the future, and thus avoided making up a new namespace (which has echoes of the discussion here). > > 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. They are indeed two separate debates, but understanding why at least some of us think it's useful, and the point about a generic namesspace, does colour what might turn out to be sensible for linker paths from here on in. i.e making up two namespaces for related purposes needs to be carefully considered. Do we get somethig important in return for that, or do we just gratuitously complicate? > > 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. Except when the existing standard is so obviously limited, and we can't change it later because it gets baked into every ABI-compatible binary for evermore. The standard was invented when there were only ever two things that got co-installed and they were easily distinguished (32 and 64-bit x86). The world is more complicated than that now. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
