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

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

 



On Fri, Jan 6, 2017 at 10:17 AM, Oron Peled <oron@xxxxxxxxxxxx> wrote:
> On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote:
>
>> ...
>
>> * I do not see any practical advantage of Debian multiarch over FHS
>
>> multilib.
>
>
>
> Good question, multiarch is a huge win for *embedded* developers.
>
>
>
> Let me give real life example from my $day job:
>
> * We build stuff for arm and x86_64 (I ignore our legacy platforms
>
> like x86, ppc, whatnot...)
>
>
>
> * We cross compile most stuff (faster), but not everything is easily
>
> cross-compilable:
>
> - Notorious examples are libraries with their own code-generation tools.
>
> - Examples: thrift, dbus-c++ (you need to *run* built tools)
>
> - So we build some packages natively (either on real ARM or in chroot with
> qemu-user-static).
>
>
>
> * With old, non-multiarch scheme:
>
> - Library packages compiled natively on ARM would be under /usr/lib.
>
> - But they cannot be installed on the build machine, so I can cross-compile
>
> applications against them.
>
> - The workaround was to unpack them, relocate the libraries, headers, etc
>
> to the prefix expected by cross compiler (e.g: /opt/toolchain/....) and
>
> repack the result into an "all" architecture package.
>
>
>
> * With multiarch distribution (Debian/jessie in my case):
>
> - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu
>
> *regardless* if they were built natively or cross-compiled.
>
> - These packages may be co-installed on my development host and be used
>
> by the cross compiler.
>
> - So I have an ARM repository, everything built (natively + cross) is
> uploaded
>
> there and I can pull library dependencies into my build environment.
>
> - And the *exact* same binary packages installed on the ARM target are
>
> installed and being used by the cross compilers.
>
>

Much of what I would have said has been said by Oron (some of this
I've said in earlier parts of this thread, as well).  But the bigger
thing is that it makes it much easier to bootstrap new architectures
for Fedora, too, as we can start from libraries and build up to
applications relatively easily. It doesn't completely solve the issue,
as there would still be some conflicts, but it makes it a lot less
challenging. Enabling things like being able to do test and
development with arbitrary architectures would be a huge boon, as
well.

That being said, I would be in remiss to indicate that platform
libdirs (what Debian calls multiarch libdirs) are able to be
implemented in a backwards-compatible way. Debian was able to pull it
off because they originally used /lib32 and /lib64, but migrated to
/lib/i386-linux-gnu and /lib/x86_64-linux-gnu (while creating symlinks
to point to them). We should be able to do the same.

The main break will be that /usr/lib will no longer contain archful
data, and that's going to be a difference no matter how you slice it.
We could elect to do /usr/lib32 and that would still be an improvement
of the situation over what we have now, but it's still a break (though
not necessarily one that will break third party applications).

If we don't want to do full platform libdirs, I would really like us
to move 32-bit libraries to /usr/lib32. It would just be much cleaner
on the filesystem that way.

If we do full platform libdirs, I would like us to have the symlinks
for /usr/lib32 and /usr/lib64 to point to the correct places, too.

-- 
真実はいつも一つ!/ 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