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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
