[PATCH] ARM: Use different linker path for hardfloat ABI
wookey at wookware.org
Fri Apr 13 13:04:42 UTC 2012
+++ 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
> 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
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:
> (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
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
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
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
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
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.
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
More information about the cross-distro