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.). 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. Jakub _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
