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

Bug#859173: ninja-build is unuseable for package cross compilation



Package: ninja-build
Severity: wishlist

Michael Biebl (Cced) asked me to look into cross compilation with meson.
meson stands on the shoulders of ninja-build, so looking into
ninja-build is the obvious first step.

ninja-build currently is an `Architecture: any` package which is
implicitly marked `Multi-Arch: no`. Resolution of `Build-Depends`
dictates that dependencies are to be considered for the host
architecture unless an annotation (`Multi-Arch` or architecture
qualifier) says something else. As it happens, a simple `Build-Depends:
ninja-build` will presently end up with the host architecture version.
During cross builds, host architecture code is usually not executable.
Trying to run `ninja-build` will thus produce an error message like the
following.

    /usr/bin/ninja-build: cannot execute binary file: Exec format error

Thus `ninja-build` is presently unusable for package[1] cross
compilation.

Now we have a problem and no obvious solution. Let me give some possible
solutions, none of which is readily applicable.

1. Mark ninja-build `Multi-Arch: foreign`. This will result in
   `ninja-build` being picked up for the build architecture and will
   thus be runnable. Other build systems like `cmake` or `make` were
   also marked `Multi-Arch: foreign`, but the devil is in the detail. We
   later noticed that `make` actually isn't fully `foreign`, because it
   considers architecture dependent paths (i.e. its behaviour differs if
   installed for a different architecture). Thus `make` now is
   `Multi-Arch: allowed` to signify that some uses are
   architecture-independent, but not all. An analysis whether
   `ninja-build` can be reasonably marked `Multi-Arch: foreign` (i.e.
   whether its interfaces vary per architecture) is presently missing.

2. As hinted in the `make` case, it could be marked `Multi-Arch:
   allowed`. This option should be considered as a last resort though,
   because it requires updating all reverse dependencies annotating
   their `ninja-build` dependency with `:any` (and checking that this is
   correct in each case), i.e. a lot of work. For `make`, this is not
   much of a problem, because `make` is pulled in by `build-essential`
   and we assume that most uses of `make` are indeed
   architecture-independent. Those rare exceptions need to gain explicit
   `Build-Depends: make` without any qualifier.

3. Not changing `ninja-build` also is an option if all relevant reverse
   dependencies annotate their `ninja-build` dependency with `:native`.
   This is only allowed for `Build-Depends`, so the `meson` binary
   package will have no way to emit a correct dependency. In a sense,
   this is a non-option.

Normally, I only report such issues with a patch. In this case, Michael
asked me to file it right away as a discussion bug to avoid any
unnecessary delay. If someone performs the necessary analysis and Ccs
debian-cross@lists.debian.org, I bet you'll get instant feedback and
review or just help with performing it.

Hope this helps

Helmut

[1] You can still install `ninja-build` for the build architecture and
    most likely have it just work. This bug is mainly about Debian's
    dependency resolution.


Reply to: