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

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

 



On Friday, 6 January 2017 19:02:16 IST Kevin Kofler wrote:

> The right way to do cross toolchains is to cross-build sysrooted packages

> from source in dedicated cross packages, which is how the Fedora cross

> toolchains work. Mixing binaries for completely different machines in the

> same directory tree, which will not even run on the host machine (or at

> best, very slowly through software emulation), strikes me as a horrible

> hack.

 

We are not talking about running binaries, but rather linking with libraries.

 

> The de-facto standard for cross compilers (i.e., what, e.g., the GNU

> toolchain supports out of the box and defaults to) is /usr/$triplet

> (sysroot), not /usr/lib/$triplet (multiarch). And that is for a reason,

> because the former can accomodate /usr/$triplet/bin, /usr/$triplet/libexec

> etc. easily

 

I've used and built such toolchains for years (thanks crosstools-ng).

They are fine if all you use them for is building "leaf" applications.

 

But when your project is composed of many developed libraries -- this is hell:

* Let's say you use your toolchain to build some libfoo shared object:

- On the target device, it may be located under /usr/lib

- But this is useless for further development, because in order to

link your applications with libfoo, it should be installed under

your $sysroot, where your toolchain will search for it

(e.g: /usr/$triplet/usr/lib)

* The common hack was to build these packages for the target

device (libraries located under /usr/lib) and than use some

"conversion" scripts that create a new package (with only libraries,

headers, pkg-config, etc.) that install them on the development

host under $sysroot.

 

With multiarch, libfoo will be always under /usr/lib/$triplet:

* On the target device, the dynamic linker will search there before

falling back to /usr/lib (for legacy libraries).

* And the Debian cross-compiler will search the same paths, so you

can install it on your development host (non-colliding directories).

 

> > * 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.

>

> That will not work with Fedora packages, for a simple reason: Fedora

> packages often contain both executables and libraries.

 

Correct. That's why I said multiarch is far greater effort than just directory

relocation and it took Debian years to reach this level.

 

In fact, if you'll read through the Debian documentation, you'll see how

many facets of the distribution it touches, from compilers and build tools,

through packaging tools and package installation tools (dpkg + apt, dependency

calculation etc.)

 

> For multilib (which does not support the cross-compilation use case you mentioned),

> RPM automatically resolves the conflict between different ELF executables by

> "coloring" them with their architecture and then preferring one "color" over

> the other. E.g., it is clear that x86_64 binaries shall always be preferred

> over i686 ones, because if you have both, you are on a 64-bit system and

> will almost always want the native ones. But if RPM sees an x86 binary and

> an ARM binary, it will have absolutely no way to decide which one to prefer,

> so it will just raise a file conflict and you will not be able to install

> the package.

 

True. One of the changes Debian introduced to "dpkg" was the concept

of secondary architectures. You can install multiarch libraries side

by side, but when you install non-multiarch package (e.g: executables)

it'll know to pick the primary architecture.

 

> For Debian multiarch to work, we would also have to introduce Debian's

> aggressive subpackaging of libraries, which is IMHO not an improvement.

 

It's true that multiarch package should contain only libraries and

not (arch-full) executables.

 

It's not an improvement for end-user system, but...

* For embedded -- regretfully, I can't even consider Fedora for embedded system development.

* Maybe also lowering total footprint (by finer granularity) which may be boon for

container people (but I haven't checked, so maybe it's not significant).

 

Overall, going multiarch is major multi-year effort, so I agree Fedora should

not jump in this direction unless it wants to cater for embedded/IoT developers.

 

If it does, I strongly suggest learning how Debian did that, both to minimize

further fragmentation as well as learning from experience of others.

 

Thanks,

 

--

Oron Peled Voice: +972-4-8228492

oron@xxxxxxxxxxxx http://users.actcom.co.il/~oron

 

"Linux is not portable (uses 386 task switching daetc.), and

it probably never will support any thing other than AT-hard

disk, as that's all I have." - Linus Torvalds, August 25, 1991.

 

_______________________________________________
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