Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux