#1134724 meson.get_compiler('vala') returns the wrong compiler

Package:
meson
Source:
meson
Submitter:
Helmut Grohne
Date:
2026-07-07 14:51:02 UTC
Severity:
normal
Tags:
#1134724#5
Date:
2026-04-23 17:05:55 UTC
From:
To:
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

#1134724#12
Date:
2026-04-23 19:41:42 UTC
From:
To:
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.

#1134724#17
Date:
2026-04-27 18:58:13 UTC
From:
To:
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.

#1134724#22
Date:
2026-04-27 19:30:06 UTC
From:
To:
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

#1134724#27
Date:
2026-07-07 14:49:49 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
meson, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1134724@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jussi Pakkanen <jussi.pakkanen@mailbox.org> (supplier of updated meson package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 07 Jul 2026 16:09:00 +0300
Source: meson
Architecture: source
Version: 1.12.0~rc1-1
Distribution: experimental
Urgency: medium
Maintainer: Jussi Pakkanen <jussi.pakkanen@mailbox.org>
Changed-By: Jussi Pakkanen <jussi.pakkanen@mailbox.org>
Closes: 1129857 1134724 1141440
Changes:
 meson (1.12.0~rc1-1) experimental; urgency=medium
 .
   * New upstream release. Closes: #1134724, #1141440, #1129857.
Checksums-Sha1:
 9776c8d43f43b116ae1af1f4fb2b3446765587b4 3558 meson_1.12.0~rc1-1.dsc
 041198968d2ea3cd314aa650de5ff600fc4a4222 2516312 meson_1.12.0~rc1.orig.tar.gz
 a9bbb6ace7fadf1297954338e4cfd00fcce16ff9 16652 meson_1.12.0~rc1-1.debian.tar.xz
 a7486ffec8deefa90219631e17c79298dd0b3768 29573 meson_1.12.0~rc1-1_source.buildinfo
Checksums-Sha256:
 9a1787c46c690d17d22bcb06fa06c193b3688308f0c691e1719289e5c47d8439 3558 meson_1.12.0~rc1-1.dsc
 23834584d070c020da7ab3ce816ec1f172999f62e83ba1ae9dab565859671c2e 2516312 meson_1.12.0~rc1.orig.tar.gz
 5ac543bae4af43aaad59da9a817d07112e9dd911765de72d1bb6e8d1b3f11c58 16652 meson_1.12.0~rc1-1.debian.tar.xz
 ce39f56553807e8b4040c2196024051feb7f5ce8e195d375e3f16e2e71d49565 29573 meson_1.12.0~rc1-1_source.buildinfo
Files:
 b56fe8c0ebed79c2bd673787371dfbc6 3558 devel optional meson_1.12.0~rc1-1.dsc
 e93dee74abc4a9641fcdda7e865e5138 2516312 devel optional meson_1.12.0~rc1.orig.tar.gz
 2123a6efb40e18e8638bd642ef5e1b58 16652 devel optional meson_1.12.0~rc1-1.debian.tar.xz
 75f698daa92f72f50897111dea8c6166 29573 devel optional meson_1.12.0~rc1-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJPBAEBCgA5FiEEGeLW2bRtjapiiPh3wk5jG6ux/nAFAmpM+vobHGp1c3NpLnBh
a2thbmVuQG1haWxib3gub3JnAAoJEMJOYxursf5w7moQAJt++hDUI2VHGa1c2fZE
1/hGXy5AbhsJi7AdEAH7LIYBsg1zBi7NwDl6uXgO3u93svmS50atprzigmgrJ5kl
v/2g4Bumx6bpEP/AuS9mD+5e8N0k8yIiunKVwXEUTV5fzV3ArB9NWJRST3igB68A
RXDHi9qQPJV5BjhIREdhiIahKg7UKeb9tIfJxQr6P7XkMhNItwtbio16Dn5TUZ9f
LdRIGG0ozMAJSt/Y+4E4iJMyQuWKPiYHSGWGqk7+h50viGbDbcHzNhdyy9H0SF75
QPVsFgROR6cDbPyW9bihZQLnyyR+lsKeYsqyYM0+7RpjsMyAZ7puiwLss1l4hEtx
DofsLQsb66TyGEF3cCyoDfiSsM5k6sdkIQwe0BSOANlKHvTrWg2/9z6o66TOVy+N
t3FWF00RstumB22vTRETUZOahaW14zJz/gpANlkfJbBtd1gP7OQhm7M27UtT6+Av
/ch0X3qdjTnCzJcYy97B95ccHnKQPy1VRttGcukhl4RzQotSVR3wKW/e0alS3XgG
bD4d7oVFYTTOWCee8Xh32n0hh1HXrFQ5zNFCn1megLvG7LbuILdqJSU9RitFCpyx
4jbD4q4WOuS2vpXzRNqv1v0FHI8nlLVV715qJfkAIicWDzAHgXj1MA0rqmM8ZfMX
Z6qnBb0qJXRgjUYaQDxasLAB
=vyxQ
-----END PGP SIGNATURE-----