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:

Disadvantages:

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:

Disadvantages:

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:

Disadvantages:

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:

Disadvantages:

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:

Disadvantages:

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:

Disadvantages:

7. Use Multi-Arch

Add a new packages:

Amend Build-Dependencies to replace versioned gcc dependencies with gcc-cross, gcc-for-build or both.

Advantages:

Disadvantages: