module/rust: set _FILE_OFFSET_BITS=64 for bindgen #15009
Conversation
|
Can you use |
|
@bonzini No, I can't. Or, at least I need help to do that. I am open to consolidate it with |
That's fair :) I was thinking of simply using the host C compiler so that if it is MSVC, which doesn't have automatic support for large files, you won't add the option to You can get it with This leaves out the case of wanting to use bindgen for the build machine, but that's not really supported at all by the |
This will fail if no C-compiler is configured. IIRC, this could be the case when using meson for Rust with bindgen, but not adding 'c' as language to Meson. Maybe I am wrong about this? Should we force detection of a C compiler when using bindgen? Or does Meson already do this? If we proceed with this: Should I use |
Hmm, good catch. I would not add the flag (the chance is small anyway, even more so if you add the chance of having off_t change the output) and warn.
I agree. |
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 host compiler.
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] rust-lang/libc#3223 (comment)
|
Thanks! I updated the code to check for the configured compiler and use |
|
Should we also check for c++, objc, and objc++ before giving up? It seems reasonable that someone could be building C++ + Rust and using C as an interface ABI. |
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.
Note that the
libccrate 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*64suffix. This is quite unfortunate, but it seems unlikely to change [1].However, use of
bindgenis usually not tied to thelibccrate. Instead, it is tied to whatever other C code in the same project does. And Meson sets_FILE_OFFSET_BITS=64unconditionally 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
libccrate very likely already uses the*64suffixed variants, they are unaffected by whether_FILE_OFFSET_BITS=64is set. If they uselibc::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.[1] rust-lang/libc#3223 (comment)