On Mon, 2017-01-09 at 07:58 -0500, Neal Gompa wrote: > On Mon, Jan 9, 2017 at 3:20 AM, Jakub Jelinek <jakub@xxxxxxxxxx> > wrote: > > On Sat, Jan 07, 2017 at 11:15:28PM +0000, Richard W.M. Jones wrote: > > > On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote: > > > > On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher > > > > wrote: > > > > > Two suggestions were raised as alternatives to the container > > > > > approach: > > > > > > > > > > * Switch to using the Debian style of multi-arch layout, > > > > > which instead of > > > > > /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. > > > > > Benefits to this would > > > > > include the emergence of a de-facto standard for system > > > > > layout between the major > > > > > distributions. > > > > > > > > Isn't this just result of good marketing of "multi-arch" > > > > distros? Because > > > > I fail to see where that approach is superior compared to what > > > > we have. > > > > > > Partly because there exist more than 2 architectures (think: > > > RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having > > > various > > > > Not all of ARM v5/6/7/8 is ABI incompatible. The FHS way of using > > suffixes > > for */lib<suffix> is able to deal with more than 2 multilibs, e.g. > > MIPS has > > 3 I think. And ISA flags you meantion (SSE, AVX) should not be > > separate > > multilib, those are just optimizations you can do in the same > > multilib, that > > can and should be resolved either completely inside of libraries > > that want > > to have optimized parts (using IFUNC, target_clones, ...) or using > > dynamic > > linker hwcaps (*/lib/sse2/, */lib/avx/ etc.). > > Unfortunately, they are only compatible in one direction. Not to > mention, from a practical perspective, ARMv8 (AArch32) and AArch64 > are > the first architectures with a solid architecture description that > everyone seems to be following. And on the other hand, you have > RISC-V, which has (IMO) too many options for how the architecture > could be defined, some of which is mutually exclusive (and thus can > cause incompatibility with itself). The way we use /usr/lib<qual> > makes it really hard to capture that effectively. > > The complexity of describing what they contain has also led to groups > within Fedora retroactively just gutting multi-lib support, so for > example, it's not easy to run ARMv7 binaries on an AArch64 system > like we decided when bringing up aarch64 that we would not support multilib as there was not a history of legacy software. all that would be needed is support in rpm/yum/dnf/mock part of the deciding factor was that the armv8 spec does not mandate that the soc support 32 bit at all. it is entirely optional. > it is for i686 binaries on x86_64. And of course, the same happened > to > POWER, though it has less effect since it's hard to find 32-bit > PowerPC binaries for Linux these days. We stopped supporting ppc on ppc64 when we stopped building ppc binaries. none of the support for it has been removed from anywhere. > Now, we could certainly bend things a little and do stuff like > /usr/lib-<arch>, but if we consider reworking this, and the goal is > to > fix the issues we have now, why not use a system that everyone else > already knows. > > > The Debian/Ubuntu system > > basically treats all architectures as cross-compiled, and > > duplicates all > > binaries. That doesn't make sense. Just because Debian/Ubuntu > > folks > > haven't understood or weren't able to implement the FHS multilibs > > and came > > up with something nonsensical doesn't mean everybody else should > > copy their > > mess. > > > > Binaries are not duplicated with the "Debian multiarch". The reason > I've been calling it "platform libdirs" is because that's what they > are: library directories marked for a specific platform triple. > Literally the Debian system just swaps /usr/lib<qual> for > /usr/lib/<arch>-<os>. (Technically, there were other things involved, > but most of them do not apply to us, because RPM has a far more > powerful mechanism for managing multiple architectures than dpkg.) > It's not true that we need to change anything (as Kevin Kofler > suggested earlier in the thread) for this to be useful. There is no > policy change required for this to be an improvement over the > situation today. > > There are two reasons for this: enabling larger scale cross- > compiling, > and supporting loading binaries intended for different architectures > or kernels. Debian maintains three kernels under its project: Linux, > HURD, and kFreeBSD. While only the Linux kernel is officially > supported now (as the bringup of the others has been very hard), the > idea behind it was that programs from i386 HURD could run on x86_64 > Linux without needing to be recompiled. Likewise, Linux binaries > could > run on kFreeBSD with little trouble. And of course, with judicious > use > of user-mode emulation, you can run ARM, PowerPC, etc. Linux binaries > on x86 Linux. > > That being said, I *don't* like how the platform libdirs are laid out > in Debian. I would have preferred something along the lines of > /usr/lib-<arch> (and leave /usr/lib for noarch libraries, like noarch > Python modules, etc.), but their system exists, and I'd prefer to > have > greater compatibility in the Linux ecosystem than not. > > And if we don't move to using platform libdirs, I would *really* like > to see us move 32-bit libraries out into /usr/lib32. There are > distribution families that use that, and frankly, it's a good cleanup > against what we have now. the only reason that aarch64 used /usr/lib64 was so it looked more like x86_64 from a user perspective, there is 64 bit arches like alpha that use /usr/lib for their libraries. Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
