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