Re: locale / encoding / meson cleanup

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(at)-@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