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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
