+++ Mike Frysinger [2012-04-09 23:57 -0400]: > 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.
No, it makes sense if want a generic scheme for avoiding linker path clashes evn if you choose not to use it for libraries too. Multilib (which you are all happy with) is just a less-generic version of the same thing. > 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. Agreed, but you do see the value in have _some_ installed at once. Why choose which ones will be useful in the future up-front? Make them all unique and you can do whatever turns out to be useful in the future. Just seems like good computer science to me. > > > 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) Yes. That doc (when you wrote this) was out of date. It described a scheme we developed last year whjich was not the one finally used (after what you might call 'lengthy internal debate'). If you look now it's up to date. (and that version has been moved to http://wiki.debian.org/Multiarch/TuplesAbandoned). Apologies for the confusion. Of course now were using triplets fairly diretly we'll be hanging around insisting that triplets do indeed indicate unique ABIs henceforth. If that's not going to be considered reasonable upstream then the tuples scheme would need to be resurrected. > > 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 ? You still don't get it do you? So long as you only look at each base arch and its ABI's independently we end up with this rather limitied naming scheme and inventing new linker paths on a 'what looks good enough today' basis. Make a generic scheme and it works for all future arches and ABIs, without us having to argue about the triplet and the linker path separately. Mind you, I read the 'case for multiarch' wiki page from your POV and I don't blame you being uninspired. It needs some work to get across to people why it's cool. I guess one thing that might seem usful to x86 people is that it makes crossgrading from a 32-bit system to a 64 bit system as simple as: (ensure both i386 and amd64 sources are avilable) dpkg --add-architecture amd64 (allow foreign arch) apt-get install dpkg:amd64 (change default arch) apt-get update; apt-get upgrade (upgrade everything to new arch) That may or may not actually work bug-free today in Debian/Ubuntu, but if it doesn't it will very soon. Similarly we can install all the cross-build dependencies for plymouth with: apt-get install -a armel build-dep -s plymouth The following packages will be REMOVED: apport gir1.2-glib-2.0 libgirepository-1.0-1 libncursesw5-dev python-gi The following NEW packages will be installed: gir1.2-atk-1.0:armel gir1.2-freedesktop:armel gir1.2-gdkpixbuf-2.0:armel gir1.2-glib-2.0:armel gir1.2-gtk-2.0:armel gir1.2-pango-1.0:armel libatk1.0-0:armel libatk1.0-dev:armel libavahi-client3:armel libavahi-common-data:armel libavahi-common3:armel libcairo-gobject2:armel libcairo-script-interpreter2:armel libcairo2:armel libcairo2-dev:armel libcomerr2:armel libcups2:armel libdatrie1:armel libdbus-1-3:armel libdbus-1-dev:armel libdrm-dev:armel libdrm-intel1:armel libdrm-nouveau1a:armel libdrm-radeon1:armel libdrm2:armel libgcrypt11:armel libgdk-pixbuf2.0-0:armel libgdk-pixbuf2.0-dev:armel libgirepository-1.0-1:armel libgnutls26:armel libgpg-error0:armel libgssapi-krb5-2:armel libgtk2.0-0:armel libgtk2.0-dev:armel libjasper1:armel libjpeg-turbo8:armel libjpeg8:armel libk5crypto3:armel libkeyutils1:armel libkms1:armel libkrb5-3:armel libkrb5support0:armel libncursesw5:armel libncursesw5-dev:armel libp11-kit0:armel libpango1.0-0:armel libpango1.0-dev:armel libpciaccess0:armel libtasn1-3:armel libthai0:armel libtiff4:armel libxcomposite-dev:armel libxcomposite1:armel libxcursor-dev:armel libxcursor1:armel libxdamage-dev:armel libxdamage1:armel libxext-dev:armel libxext6:armel libxfixes-dev:armel libxfixes3:armel libxft-dev:armel libxft2:armel libxi-dev:armel libxi6:armel libxinerama-dev:armel libxinerama1:armel libxrandr-dev:armel libxrandr2:armel x11proto-composite-dev x11proto-damage-dev x11proto-fixes-dev x11proto-randr-dev x11proto-xext-dev x11proto-xinerama-dev The following packages will be upgraded: libcomerr2 libgnutls-dev libgnutls-openssl27 libgnutls26 libgnutlsxx27 (Just to illustrate that it works for non-trivial cases). Then cross-build it all with dpkg-buildpackage -aarmel No messing about with chroots or sysroots or installing build-deps to funny paths required (although of course chroots and sysroots also still work, and are useful for lots of reasons). It's the symmetry that the really nice thing. Anyway, I digress rather now - I'll update the wiki page. 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
