Re: Bug#859177: meson is unuseable for package cross compilation
On Fri, Mar 31, 2017 at 02:41:55PM +0300, Jussi Pakkanen wrote:
> Meson requires access to the "native" and "cross" compilers at the
> same time. This is because it natively supports the use case where you
> compile a program that is then used to generate source code that is
> built. Examples include idl compilers and the like. I'm not familiar
> enough with the Debian cross compilation environment to know if those
> are available.
The standard way to get the build architecture compiler (what you call
native) is to simple use the plain compiler (e.g. `gcc`) without any
fuss.
The standard way to get the host architecture compiler (what you call
cross) is the plain compiler name prefixed with the GNU triplet. Let me
give an example here. If you cross build for `armhf` (Debian
architecture), `dpkg-architecture -aarmhf` tells us that the GNU triplet
is `arm-linux-gnueabihf`. Thus the actual compiler is called
`arm-linux-gnueabihf-gcc`. The `makefile` buildsystem in `debhelper`
even just sets `CC=${DEB_HOST_GNU_TYPE}-gcc`. The convention is: prefix
host tools with the host's GNU triplet.
This approach doesn't just work for `gcc`, it works for all of gcc's
frontends, binutils, pkg-config, and even python-config. It also tends
to work on other distributions (once you know the GNU triplet).
> Something like this could be done and possibly even provided upstream.
> However I'd like it to first go to Debian for a while. If it lives
> upstream it would need to support many distros (at least Debian +
> Fedora, preferably also Arch and the like). Getting it running on a
> single distro is a lot simpler.
I agree that shipping this as a Debian-ism may prove easier for
development of the thing. As you are the maintainer and agree with that
idea, it sounds like a plan. Still, I would like to avoid using any
Debianisms in the implementation (as CMake still does in some parts) to
ease upstreaming down the road.
The more radical approach would be adding a `--host` or `--host-arch`
option to `meson` itself. It could be setting different defaults and
still allow passing a `--cross-file` to override.
> There is, however, an alternative to this. There is only one cross
> file per architecture, so for Debian a few dozen. Those could be
> manually generated and provided as part of dh_meson package or
> somesuch. Then getting a cross compilation going would be just a case
> of adding this to the configuration line:
>
> --cross-file /usr/share/something/triplet-filename.txt
The idea is correct in principle, but it suffers from three flaws.
Beyond build and host architectures, meson appears to have limited
support for target (as you mentioned below). Adding the target into the
mix means squaring the number of files. The second flaw is that some
aspects of the build architecture may vary. If that turns out to happen,
the number of files becomes the number of architectures to the power of
three. I'm working on 36 architectures, so 46656 files. dpkg knows about
523 architectures, i.e. 143055667 files. Furthermore, we'll sometimes
have to "fix" these `--cross-file`s for individual source packages.
Thus the `cross-meson` utility should be able to receive a
`--cross-file` overlay to be able to override any setting a maintainer
wishes to change. Otherwise, they'll just opt out of using `cross-meson`
and get things wrong. Keeping the flexibility seems important to me.
For these reasons, I believe that just storing them statically is
infeasible.
> This is especially useful if there are platforms that require tweaks
> to the cross files that the generator would create. This gets a bit
> more complicated if compiling cross compilers or binutils, which would
> require having a different cross file where host is different from
> target. At the time of writing there are no compilers building with
> Meson that I know of so this is not an acute issue.
Before too long, I expect `meson` to be picked up for compilers. We
should be prepared for that case.
Briefly looking into `mesonlib.default_libdir`, it seems that `meson`
already hooks into Debian-specifics. The hack in
`mesonlib.get_library_dirs` looks even worse as it will be wrong on a
pile of architectures and for cross compilation. I wonder why
`dpkg-architecture` is used in `default_libdir`, but not
`get_library_dirs`. That looks inconsistent to me. :-(
Does any reader of `debian-cross@lists.debian.org` object to just
marking `meson` `Multi-Arch: foreign` on the grounds that even if it may
be wrong, any other value makes even less sense?
Helmut
Reply to: