You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My understanding is, that it is very common to wrap a C library in a Rust *-sys crate by using bindgen to automatically generate Rust bindings and cc to compile the C code.
As far as I understand it bindgen uses libclang to parse the C headers and cc uses whatever compiler the user provides.
This can lead to problems, because both toolchains don't need to agree on everything. While cross compiling for thumbv6m-none-eabi on Windows, bindgen generated u32 for enums and cc used u8 when possible (-fshort-enums).
This is quite unfortunate and hard to catch. Is there a common workaround for this?
PS: If there is a better place for this issue please tell me.
The text was updated successfully, but these errors were encountered:
The docs for Build::compiler also say that the compiler is automatically detected from a number of environment variables so it might be that setting CC or similar to be consistent with the clang-sys environment variables might work as well.
My understanding is, that it is very common to wrap a C library in a Rust
*-sys
crate by usingbindgen
to automatically generate Rust bindings andcc
to compile the C code.As far as I understand it
bindgen
useslibclang
to parse the C headers andcc
uses whatever compiler the user provides.This can lead to problems, because both toolchains don't need to agree on everything. While cross compiling for
thumbv6m-none-eabi
on Windows,bindgen
generatedu32
for enums andcc
usedu8
when possible (-fshort-enums
).This is quite unfortunate and hard to catch. Is there a common workaround for this?
PS: If there is a better place for this issue please tell me.
The text was updated successfully, but these errors were encountered: