Armhf dynamic linker path
vapier at gentoo.org
Thu Apr 5 01:18:13 UTC 2012
On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote:
> On 3 April 2012 02:56, Mike Frysinger wrote:
> > On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote:
> >> yes, this was brought up at Linaro Connect as well; having the ldso name
> >> in a multiarch location doesn't mean that anything else needs to be in
> >> this location.
> > while true, it seems like /lib/<ldso> vs /lib/<multiarch>/<ldso> needs
> > to be handled by the multiarch people regardless (for historical
> > support), while non-multiarch peeps never have /lib/xxx/ subdirs.
> > i know it's a bit of bike shedding, but if the mainline standard is
> > /lib/<ldso> and multiarch peeps have to deal with that already, it'd
> > make more sense to stick with /lib/<ldso>.
> For some value of "mainline standard":
> Quite clear there has been no effort in naming except in the few cases
> "something" was hacked in to allow coinstall of 64bit binaries.
we all agree arm's current situation is f-ed. however, i don't agree with
your analysis of any of the other targets. they all look sane to me.
> The choice of using multiarch path for armhf linker path was agreed
> mostly because 1) people agreed that having the possibility of armhf
> and armel binaries on the same systems is useful and 2) nobody
> proposed anything else.
i don't see value in having multiple endians being active simultaneously. it
might make for a fun exercise, but people won't deploy systems with them both
installed. after all, the kernel isn't bi-endian on the fly.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the cross-distro