On Wed, Apr 04, 2012 at 09:18:13PM -0400, Mike Frysinger wrote:
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":
https://wiki.linaro.org/RikuVoipio/LdSoTable
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. -mike
Do you mean multiple ABIs? The kernel does support both EABI (Debian's armel) and EABI/Hardfloat (Debian's armhf) concurrently, and there are realworld reasons you'd want to do it (e.g. closed armel Xorg drivers, but an otherwise armhf-optimized system).
-dann