diff options
| author | David Rheinsberg <david@readahead.eu> | 2025-09-08 14:12:21 +0200 |
|---|---|---|
| committer | Dylan Baker <dylan@pnwbakers.com> | 2025-10-15 08:32:38 -0700 |
| commit | 2780f41723967f63b91a2999a79bb009d00b6065 (patch) | |
| tree | 295e71a903ab06e6c261103dfbc2ccc1974885ef /mesonbuild/modules/rust.py | |
| parent | 39ebb8598206d92b1f1f49b7589b7e299175683c (diff) | |
| download | meson-2780f41723967f63b91a2999a79bb009d00b6065.tar.gz | |
module/rust: set _FILE_OFFSET_BITS=64 for bindgen
Meson sets 64-bit offsets as the default for all platforms but MSVC.
Lets do the same for bindgen, to ensure we get compatible definitions.
Do this by calling `get_always_args()` on the first C'ish host compiler
we can find.
Note that the `libc` crate does not expose 64-bit types as the default
and there is no intention to do so. Instead, it exposes 32-bit default
types, plus the 64-bit extended types with the `*64` suffix. This is
quite unfortunate, but it seems unlikely to change [1].
However, use of `bindgen` is usually not tied to the `libc` crate.
Instead, it is tied to whatever other C code in the same project does.
And Meson sets `_FILE_OFFSET_BITS=64` unconditionally for all this C
code. It thus seems much more plausible for Meson to also imply it for
bindgen.
Given that Rust code that uses the `libc` crate very likely already uses
the `*64` suffixed variants, they are unaffected by whether
`_FILE_OFFSET_BITS=64` is set. If they use `libc::off_t`, they already
explicitly state that they use the 32-bit variant on 32-bit platforms.
Hence, it is inherently incompatible to C code that uses
`_FILE_OFFSET_BITS=64`.
And lastly, if a Meson project is Rust-only, but generates its internal
code from its public C headers, then it is better suited to actually
call `add_language('c')` and ensure that Meson knows what the compiler
configuration for the target platform actually is. Otherwise, bindgen
cannot know what platform options to enable. Hence, warn loudly if
`rust.bindgen()` is used without a configured C compiler (even if the
compiler used by bindgen does not necessarily match the configured one).
[1] https://github.com/rust-lang/libc/issues/3223#issuecomment-2033298952
Diffstat (limited to 'mesonbuild/modules/rust.py')
| -rw-r--r-- | mesonbuild/modules/rust.py | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/mesonbuild/modules/rust.py b/mesonbuild/modules/rust.py index 59702d756..afcad98df 100644 --- a/mesonbuild/modules/rust.py +++ b/mesonbuild/modules/rust.py @@ -5,6 +5,7 @@ from __future__ import annotations import itertools import os import re +import textwrap import typing as T from mesonbuild.interpreterbase.decorators import FeatureNew @@ -337,6 +338,24 @@ class RustModule(ExtensionModule): # TODO: if we want this to be per-machine we'll need a native kwarg clang_args = state.environment.properties.host.get_bindgen_clang_args().copy() + # Find the first C'ish compiler to fetch the default compiler flags + # from. Append those to the bindgen flags to ensure we use a compatible + # environment. + comp = mesonlib.first( + [state.environment.coredata.compilers.host.get(l) for l in ['c', 'cpp', 'objc', 'objcpp']], + lambda x: x is not None, + ) + if comp: + clang_args.extend(comp.get_always_args()) + else: + mlog.warning(textwrap.dedent('''\ + Using `rust.bindgen` without configuring C (or a C-like) + language in Meson will skip compiler detection and can cause + ABI incompatibilities due to missing crucial compiler flags. + Consider calling `add_languages('c')` in your Meson build + files. + ''')) + for i in state.process_include_dirs(kwargs['include_directories']): # bindgen always uses clang, so it's safe to hardcode -I here clang_args.extend([f'-I{x}' for x in i.to_string_list( |
