On Mon, Jan 9, 2017 at 3:20 AM, Jakub Jelinek <ja...@redhat.com> 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 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. 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
