Oron Peled wrote:
> * 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.
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.
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 (or even /usr/$triplet/usr/bin etc. if desired, though in the
current UsrMove world, those would likely be at most symlinks to the
non-/usr variant), the latter cannot.
> * 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. 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.
For Debian multiarch to work, we would also have to introduce Debian's
aggressive subpackaging of libraries, which is IMHO not an improvement.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
