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