On Mon, Jan 09, 2017 at 09:20:20AM +0100, Jakub Jelinek 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, ...) I should note that RV64G vs RV64GC (compressed) is not something that could be handled by ifuncs. It's a deep change that affects all the generated code. I'm hoping that every other RISC-V extension _can_ be handled only using ifuncs/target_clones etc. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
