On Wednesday 04 April 2012 21:31:20 dann frazier wrote:
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>.
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.
Do you mean multiple ABIs?
no -- i said "endian" here a few times. i agree that multiple ABIs makes sense. (let's not pointlessly nitpick endian encoding as part of the ABI and just go with what people more commonly use.)
The kernel does support both EABI (Debian's armel) and EABI/Hardfloat (Debian's armhf) concurrently
too bad the OABI shim is buggy :( -mike