On Monday 09 April 2012 23:07:14 Wookey wrote:
/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.
this logic really only makes sense if you're talking about multiarch. many people still don't see the point in having many architectures installed simultaneously in a single system. it's a "problem" that doesn't really exist.
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.
how can you mix n32 and n64 libs ? the sizes of pointers are different.
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).
that's not what the wiki says: http://wiki.debian.org/Multiarch/Tuples
(i'm not saying you're wrong, just that my only source of multiarch info is the aforementioned wiki)
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?
in this case, it comes back to a simple question: do we plan on supporting old abi and armhf simultaneously ? if no one cares, then /lib/<unique lds> is the simple answer. if people want multilib, then /libhf/<ldso> is the answer.
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.
i think it's still pretty simple ;) -mike