gnome-nibbles (and probably a lot more) fails to cross build from
source, because meson misdetects the vala compiler. Its meson.build goes
meson.get_compiler('vala') and while that should be returning a host
compiler, it ends up returning a native one. It should be looking up the
compiler from the crossfile, but it ignores an assignment there. This is
due to the detection method ignoring the given MachineChoice and
erroneously passing MachineChoice.BUILD to the environment lookup. Once
returning the correct vala compiler, gnome-nibbles cross builds
successfully.

I am attaching a patch that corrects this mistake. It is written in a
backwards-compatible way: If the environment does not mention a vala
binary, it falls back to the native tool.

Given the lack of feedback on other patches, I am considering to NMU
this and other patches. Please let me know if you prefer not having it
NMUed.

Helmut

I'm currently doing the upload of the next version, but I'll look into
this soon.

The think I'd /really/ prefer is getting /all/ patches upstream first.
The goal of Meson packaging is to have zero functional patches in
packaging. Juggling patches in multiple different places is not nice.

I posted this up on Meson's PRs:

https://github.com/mesonbuild/meson/pull/15736

There were several issues raised. First of all there was a person who
said that according to certain Gnome devs Vala cross compiling is a
ill-defined. Sadly I don't have a proper link upstream but it might be
that it is not supported (though works in most cases).

But the bigger issue is that in Meson valac is treated specifically as a
regular compiler even in cross compilation contexts because it only
produces C source code that is then compiled by the cross compiler.
Changing that in the way this patch suggests changes pretty much the
whole way Vala handling is done in Meson.

This really should get a proper fix. Probably a way to get started on
that is to get the actual error messages for a failed cross build.

Hi Jussi,

Thank you! I followed up there.

I agreed somewhat, but even when it is not well-defined, we can draw
some conclusions relibaly.

That is very plausible.

This is an architectural bug in Meson. valac is able to call the C
compiler and that way is architecture-dependent. It is not only
producing C source code. You may point out that the way Meson uses valac
never makes it run the C compiler and I'd trust you on that. However,
valac also calls pkgconf and that's not a theoretical result. We can
observe those pkgconf calls (fail) in actual cross builds. The calling
of pkgconf is sufficient to make valac architecture-dependent and that
is sufficient to make Meson's way of treating vala architecturally
broken.

Thank you for looking at the wider picture. This is the way to make
forward progress. When I filed the bug, I included an example package
demonstrating the faulty behavior. It is gnome-nibbles. We can easily
check cross build logs at https://crossqa.debian.net/src/gnome-nibbles.
The most recent failure is
https://crossqa.debian.net/build/gnome-nibbles_1:4.5.1-1_i386_20260423064329.log

| Dependency libadwaita-1 for host machine found: YES 1.9.0 (cached)
| Run-time dependency pango found: YES 1.57.1
| Found CMake: NO
| Run-time dependency gtk5 found: NO  (tried pkg-config and cmake)
| Library posix found: YES
| Compiler for C supports arguments -w: YES
| Checking if "an array of strings links without casting?" links: NO
| Message: Vala has a bug when passing a constant array of strings to a function, workaround applied.
| Checking if "static local functions can be used without casting?" with dependency gio-2.0 links: NO
| Message: Vala static local functions need casting to static delegates.
| Checking if "we can link with libadwaita?" with dependency libadwaita-1 links: NO
|
| ../meson.build:117:4: ERROR: Problem encountered: Can not link with libadwaita.
|
| A full log can be found at /build/reproducible-path/gnome-nibbles-4.5.1/obj-i686-linux-gnu/meson-logs/meson-log.txt

Checking the meson-log.txt (later in the log), we see:

| Command line: `valac /build/reproducible-path/gnome-nibbles-4.5.1/obj-i686-linux-gnu/meson-private/tmpy8ujzbhr/testfile.vala --pkg=libadwaita-1 --Xcc=-w` -> 1
| stdout:
| Compilation failed: 1 error(s), 0 warning(s)
| -----------
| stderr:
| Package gobject-2.0 was not found in the pkg-config search path.
| Perhaps you should add the directory containing `gobject-2.0.pc'
| to the PKG_CONFIG_PATH environment variable
| Package 'gobject-2.0' not found
| error: pkg-config exited with status 256
| -----------
| Checking if "we can link with libadwaita?" with dependency libadwaita-1 links: NO
|
| ../meson.build:117:4: ERROR: Problem encountered: Can not link with libadwaita.

Here you see that meson runs the build architecture valac when it should
be running the host architecture on. You can also see that it passes
--pkg=libadwaita-1, which is a host dependency and you see that pkgconf
is unable to locate required dependencies. What you do not see is that
the build architecture pkgconf was used and that that was the reason to
fail here. Once you make Meson call i686-linux-gnu-valac, the host's
pkgconf is used and the whole build succeeds.

Your feedback is appreciated. Is there anything else I can provide to
move things forward?

Helmut