Bug#889925: valac is unusable for cross-compilation

Helmut Grohne helmut at subdivi.de
Thu Feb 8 20:26:14 UTC 2018


Source: vala
Version: 0.38.7-1
User: helmutg at debian.org
Usertags: rebootstrap

valac is presently unusable for cross-compilation. There are a number of
issues and unfortunately, this isn't going to be fixable easily.

The first issue you bump into is that executing valac gives an "Exec
format error". This is typical for build tools being installed from the
host architecture. As it happens, valac is implicitly marked Multi-Arch:
no, so it is installed for the build architecture. The simple fix for
this is to mark it Multi-Arch: foreign. Unfortunately, that is not
correct.

valac runs gcc and pkg-config. Both of these tools have
architecture-dependent behaviour and valac inherits that
architecture-dependence. Thus marking it Multi-Arch: foreign is wrong.
The typical solution to this problem is to encode the architecture into
the program name. On amd64, you can call gcc as x86_64-linux-gnu-gcc and
you can call x86_64-linux-gnu-pkg-config. However, these later
invocations also work for cross compilation. So what we need here is
adding the architecture to the valac command name.

In the simplest case, we could do:

    ln -s valac .../usr/bin/${DEB_HOST_GNU_TYPE}-valac

Unfortunately, that won't fix any cross compilation issues. What we'd
want here is to have a valac executable for the build architecture
running the tools for another architecture. Thus I propose adding the
following shell script to the valac binary package:

    #!/bin/sh
    exec valac "--cc=${CC:- at DEB_HOST_GNU_TYPE@-gcc}" "--pkg-config=${PKG_CONFIG:- at DEB_HOST_GNU_TYPE@-pkg-config}" "$@"

You'd interpolate @DEB_HOST_GNU_TYPE@ at package build time and install
it as /usr/bin/${DEB_HOST_GNU_TYPE}-valac. It'd run valac with the
appropriate compiler and pkg-config for the prefix it was installed as.

Now that still doesn't fix the "Exec format error". So we'd also need a
new binary package (probably called "valac-bin"), move /usr/bin/valac to
that new package, add a dependency from valac to the new package and
mark the new package Multi-Arch: foreign. That's not fully correct as
valac is still architecture-dependent, but anyone wanting a particular
architecture's behaviour can and should simply run
${DEB_HOST_GNU_TYPE}-valac. We do the same for pkg-config and that
appears to work fairly well. Consumers need to add this prefix of course
and I sent a patch for AM_PROG_VALAC (#889920) already.

Implementation plan:
 * Create a new binary package valac-bin.
 * Move /usr/bin/valac to valac-bin (add Breaks/Replaces).
 * Add a valac-bin (= ${binary:Version}) to valac's Depends.
 * The description of valac-bin should say something like "don't install
   this package directly use valac instead". It should make clear that
   valac-bin is an implementation detail.
 * Mark valac-bin Multi-Arch: foreign.
 * Add the above script as /usr/bin/${DEB_HOST_GNU_TYPE}-valac to the
   valac binary package.

Do you agree with that approach? Can you help implement it?

Helmut



More information about the pkg-gnome-maintainers mailing list