Re: Bug#859177: meson is unuseable for package cross compilation
On Fri, Mar 31, 2017 at 4:31 PM, Helmut Grohne <helmut@subdivi.de> wrote:
> 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 does not work. For Meson, CC always means "the native compiler".
This is just a matter of unsetting that var (or making it point to
/usr/bin/cc, whichever is 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.
AFAICR CMake has a similar concept of a toolchain file for cross
compilations. How are they dealt with in Debian?
> 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.
In Meson we avoid making absolutely everything configurable in a
gazillion different ways. It just leads to frustration. We prefer
explicit data in (preferably only one) place and for cross compilation
that is the cross file. Having one plain text file with all the
information makes e.g. debugging a lot simpler.
>> 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.
Those numbers are a bit off. Information about the build machine is
not stored in the cross file, it is detected at runtime, identically
to how native building would work. Thus cross compiling for 36
architectures would require 36 files or 72 if accounting for cases
where target is specified but host is not. You'd only need to go to
36*36 = 1296 files if you want to support cross compiling cross
compilers on all possible combinations.
That being said generating them live is probably a good approach, it
seems to be mostly a question of mangling the output of
dpkg-architecture.
> 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. :-(
That is old code that is not used much any more. Nowadays we don't do
library lookups based on file paths but instead by asking the compiler
(i.e. we know library 'foo' is available if compilation with the
desired compiler when using '-lfoo' passes.
Still, that should probably be fixed at some point.
Reply to: