|
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
