On 2026-08-26 We 10:08 AM, Nazir Bilal Yavuz wrote:
0004 makes the meson build report the GNU host triplet, by asking the
compiler
for it with -dumpmachine where it supports that and falling back to the
present
behaviour otherwise.
+host_tuple = '@0@-@1@'.format(host_machine.cpu_family(), host_system)
+if cc.get_id() in ['gcc', 'clang']
+ dumpmachine = run_command(cc.cmd_array(), '-dumpmachine', check: false)
I think we need to add c_args here, like:
dumpmachine = run_command(
cc.cmd_array() + get_option('c_args'), '-dumpmachine', check: false)
There could be a '--target' in the c_args which might affect the result [2].
[2] https://clang.llvm.org/docs/ClangCommandLineReference.html
Here's a reworked patch 4. I asked Claude for a review of the changes
and inconsistencies, and got this:
What it fixes:
- The original bug (meson's cpu_family-system never carrying the ABI
suffix) — fixed for gcc/clang builds.
- Bilal's c_args/--target gap — if you pass -Dc_args=--target=...,
the reported triplet now reflects the actual compile target instead of
the compiler's untargeted default.
What it doesn't fully close:
1. gcc vs. clang now disagree with each other on the same host. I
verified this directly during review: gcc -dumpmachine →
aarch64-linux-gnu, clang -dumpmachine → aarch64-unknown-linux-gnu. Both
satisfy the
two tests' regexes, so nothing breaks functionally, but version()'s
platform substring is no longer mechanically identical across compilers
on identical hardware — before this patch it was (always
cpu_family-system, compiler-independent, just wrong). That's a new,
narrower form of inconsistency this patch introduces as a side effect of
the fix.
2. Meson vs. autoconf agreement isn't structurally guaranteed, only
empirically true for ordinary distro toolchains. Autoconf's string comes
from config.guess/config.sub's own normalization; -dumpmachine
reports whatever triple the specific compiler was built to report.
They usually coincide because distro gcc/clang packages are typically
built with --target equal to their config.guess triple — but a
custom-built compiler with an unusual target string would make meson
and autoconf diverge on the identical host, since nothing here
normalizes -dumpmachine's output against GNU's canonical form.
3. Non-gcc/clang meson builds (MSVC, etc.) still fall back to the old
cpu_family-system format — unchanged, no regression, but also no
consistency gain there. There's no autoconf reference point for MSVC
anyway, so this doesn't matter in practice.
So: real inconsistencies removed (the two test guards, the --target
blind spot), one new narrow one accepted as a trade-off
(compiler-dependent vendor field), and one that was never a hard
guarantee to begin
with (meson vs. autoconf on unusual toolchains).
So, two questions: do we want this at all? After all, we have lived with
the inconsistencies for a while with few ill effects. And if we do, do
we want it for release 19?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From 1054a9443fa420f7e3c15a118b6bb3dcf9a214d4 Mon Sep 17 00:00:00 2001
From: Andrew Dunstan <[email protected]>
Date: Sat, 22 Aug 2026 17:21:02 -0400
Subject: [PATCH v2] meson: report the GNU host triplet in PG_VERSION_STR
The meson build composed the platform part of PG_VERSION_STR from
host_machine.cpu_family() and host_system, producing strings like
"aarch64-linux", where configure substitutes the GNU host triplet,
"aarch64-unknown-linux-gnu". Two regression tests match against that
string, and both have quietly been doing the wrong thing on meson builds
ever since meson support arrived in 16. Those have been fixed now, but
the differences remain.
Fix by asking the compiler for its own target triplet with -dumpmachine
where it supports that, falling back to meson's idea of the host
otherwise.
Discussion: https://postgr.es/m/[email protected]
---
meson.build | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index f4cde249242..779881c8880 100644
--- a/meson.build
+++ b/meson.build
@@ -3293,10 +3293,27 @@ cdata.set('MEMSET_LOOP_LIMIT', memset_loop_limit)
cdata.set_quoted('DLSUFFIX', dlsuffix)
+# configure substitutes the GNU host triplet into PG_VERSION_STR, and some
+# regression tests match against it: collate.linux.utf8 looks for "linux-gnu",
+# and infinite_recurse looks for "powerpc64[^,]*-linux-gnu". Meson's own idea
+# of the host is just cpu_family-system, which never contains the ABI suffix,
+# so ask the compiler for the triplet when it can tell us.
+host_tuple = '@0@-@1@'.format(host_machine.cpu_family(), host_system)
+if cc.get_id() in ['gcc', 'clang']
+ # Include c_args: a --target passed there (clang cross-builds) changes
+ # what the compiler actually targets, and -dumpmachine needs to see it
+ # too, or it reports the untargeted default instead.
+ dumpmachine = run_command(cc.cmd_array() + get_option('c_args'),
+ '-dumpmachine', check: false)
+ if dumpmachine.returncode() == 0 and dumpmachine.stdout().strip() != ''
+ host_tuple = dumpmachine.stdout().strip()
+ endif
+endif
+
# built later than the rest of the version metadata, we need SIZEOF_VOID_P
cdata.set_quoted('PG_VERSION_STR',
- 'PostgreSQL @0@ on @1@-@2@, compiled by @3@-@4@, @5@-bit'.format(
- pg_version, host_machine.cpu_family(), host_system,
+ 'PostgreSQL @0@ on @1@, compiled by @2@-@3@, @4@-bit'.format(
+ pg_version, host_tuple,
cc.get_id(), cc.version(), cdata.get('SIZEOF_VOID_P') * 8,
)
)
--
2.43.0
