On Monday 09 April 2012 16:48:06 Adam Conrad wrote: > On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote: > > On 4 April 2012 18:54, Jakub Jelinek wrote: > > > If the agreement is that arm 32-bit softfp really needs to be > > > installable alongside 32-bit hardfp (and alongside aarch64), then IMHO > > > it should do it like all other multilib ports (x86_64/i?86/x32, > > > s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, > > > e.g. use > > > /lib/ld-linux.so.3 and */lib dirs for softfp, > > > /libhf/ld-linux.so.3 and */libhf dirs for hardfp and > > > /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit > > > arm-linux-gnueabi gcc configured for softfp/hardfp multilib with > > > MULTILIB_OSDIRNAMES, etc., have it configured in glibc > > > > OK. This gives a different path for the hard float loader and lets > > the Debian guys add on top of that. I'll ping them and see what they > > think. > > The problem here that everyone !Debian isn't taking into account is that > multilib paths don't solve our use-case. Multilib paths only solve the > case of multiple ABIs on the same base processor family. As soon as you > combine x86, arm, power, etc, you end up with overlaps
and the problem there is that you're assuming anyone !Debian sees this as a
problem. so, once again, do not use the armhf standardization work to
backdoor multiarch. if you want to talk about multiarch, then start a new
thread to do that.
> Ultimately, however, I want this solved. We thought we had this solved at
> Plumbers last fall. To hear now that we "didn't involve everyone" is
> disheartening, given that we ("we" being Debian and Ubuntu) were well
> outnumbered in that room by people from RedHat, Fedora, ChromeOS, and
> Gentoo.
tbh, i thought the ldso discussion was more "we've been talking about this for
a long time, so let's just go with XXX" and then people moved on to the next
topic (which was defining exactly what "hard float abi" meant wrt compiler
flags). further, it seemed like we had distro representation there, but not
mainline gcc people.
> So, pretty please, can we (A) address the concerns here without people
> putting up the "Unique paths are Debian trying to force multi-arch on us"
> straw man, and (B) agree to *something*, before I ship something that
> conforms to a standard agreed upon more than half a year ago that is now
> a cause for contention? Pretty please? With sugar on top? Kthx.
again, saying "/lib/<tuple>/<ldso>" isn't multiarch is bunk. but it sounds
like you're fine with /libhf/, so there isn't anything left to thrash about
there.
-mike
signature.asc
Description: This is a digitally signed message part.
