To make the base system cross-buildable it is necessary to have a mechanism that translates explicit build dependencies on compilers and other packages that produce native code to their cross variants. If a source package build dependes on gcc-4.8, then it has to depend on gcc-$host-4.8 when cross compiled for host architecture $host.
The solution of this has to be coordinated with Cross Toolchains in the archive and would be greatly improved by having Co-installable Compilers.
A daily updated list of source packages that suffers from this problem can be found on http://bootstrap.debian.net/cross.html in the "conflict" table.
Seven possible solutions
1. New Build-Depends syntax extension
Build-Depends: gcc-${host} (>= 4.8)When parsing the above, the "${host}" bit would be replaced by the host architecture name by all crossbuild dependency resolvers.
Advantages:
- subjectively most elegant and intuitive
Disadvantages:
requires changes to all tools that parse build dependencies (see BuildProfileSpec for a list)
- packages with the new syntax can only be uploaded when the first release with the necessary changes is made (just like with build profiles)
2. Use build profile syntax
Build-Depends:
gcc-4.8 <!profile.cross>,
gcc-alpha-4.8 <profile.cross> [alpha],
gcc-amd64-4.8 <profile.cross> [amd64],
gcc-arm64-4.8 <profile.cross> [arm64],
[...]Advantages:
- no changes to any tool needed - works automatically through build profiles
Disadvantages:
- very long dependency lists
- has to be updated for each new port
3. Use restriction syntax with new namespace
Build-Depends:
gcc-4.8 <cross.translate>The annotation marks the build dependency on gcc-4.8 as to-be-translated to its cross variant.
Advantages:
- only needs adaption of tools involved in cross compilation (dpkg-checkbuilddeps, apt-get build-dep)
Disadvantages:
- the information to what package name to translate the build dependency to has to be stored somehow (additional field?)
4. New field for to-be-translated tools
Compilers would have a field like this added:
Needs-cross-translation: Yes
If a source package build depends on a binary package with that field it would know that during cross compilation, that dependency would have to be translated to a cross variant of that package. There could be a global naming scheme like adding "-$hostarch" to the base package name for the cross variant.
Advantages:
- only needs adaption of tools involved in cross compilation (dpkg-checkbuilddeps, apt-get build-dep)
Disadvantages:
- no way to selectively disable translation
- the information to what package name to translate the build dependency to has to be stored somehow (additional field?)
5. Central list of to-be-translated tools
Like above but instead of the packages storing the information whether or not they have to be translated, the information would be stored centrally (for example by dpkg).
Advantages:
- only needs adaption of tools involved in cross compilation (dpkg-checkbuilddeps, apt-get build-dep)
Disadvantages:
- no way to selectively disable translation
- the information to what package name to translate the build dependency to has to be stored somehow (additional field?)
6. New Build-Depends syntax extension local to debian/control
Introduce the syntax extension of gcc-${host} like in option (1) but let dpkg translate such a build dependency to the format of option (2) during package compilation.
Advantages:
- only needs updating of dpkg
- as elegant and intuitive as option (1)
Disadvantages:
- for each new port affected packages have to be recompiled to refresh their Build-Depends list (still better than having to do it manually as with option (2))
7. Use Multi-Arch
Add a new packages:
gcc-<triplet> being Arch:any M-A:foreign and depending on the native gcc (needed for native compiling).
gcc-cross being Arch:any M-A:same depending on gcc-<triplet>.
gcc-for-build being Arch:any M-A:same depending on gcc.
Amend Build-Dependencies to replace versioned gcc dependencies with gcc-cross, gcc-for-build or both.
Advantages:
- No syntax modification
- Not ugly
Disadvantages:
- Many new binary packages
- It is possible to install compilers that cannot be executed.