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
I'm working on using Bindgen 0.71.1 to add Rust bindings for a library with several hundred header files. The library makes extensive use of atomics (which I know Bindgen won't handle) and static inline functions. So far, I have not needed to directly interact with any variable or function that is or accepts atomic types, so I have built up an extensive block list of symbols that I know are in problematic headers, contain problematic arguments, etc.
However, despite my best efforts to start small and include more headers as I go, I still find that I'm running into the following error whenever I turn on .wrap_static_fns(true) and include the Nth + 1 header file (either one individually is fine).
--- stderr
clang diag: warning: argument unused during compilation: '-L/nix/store/cavvlmkzzyvyabqlkqxwjq3y9s8lxjjd-xxxx-0000/lib' [-Wunused-command-line-argument]
thread 'main' panicked at build.rs:1112:6:
Unable to generate bindings: Codegen(Serialize { msg: "Cannot serialize type kind Opaque", loc: "builtin definitions" })
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The problem isn't that Bindgen can't generate bindings for the symbol -- I expect that Bindgen won't be able to handle 100% of this library. The problem is that the error gives absolutely no indication which symbol it is choking on, nor which symbol cause that symbol to be pulled into the binding list.
I've attempted to attach a debugger to the build-script-build and step through bindgen to see if I could locate the name of the symbol (or better yet, the name of at least one symbol that caused it to be added to the bindings). However, it seems all the symbols are placed into a large flat map structure and my debugger can't quite chase down through the structs to read the .name member.
For any sufficiently large library, it's intractable to build up an allow list because the transitive closure grows too quickly. At the same time, this error is preventing the use of a block list because I cannot divine which symbol to block.
An alternative to including the symbol information in the error output would be to automatically prune symbols Bindgen can't handle instead of panicking, but that's likely a much larger change.
I don't think the build.rs will be too helpful, as the reproduction is essentially the same as #2151, but in case it does make a difference, here's the gist of it:
let bindings = bindgen::Builder::default()
// This header file transitively includes everything that bindings are needed for.
.header("wrapper.h")
// Tell Bindgen where to find headers and shared libraries
.clang_arg(format!("-I{}", include_dir))
.clang_arg(format!("-L{}", lib_dir))
// These variables are defined with Thread-Local Storage (TLS (not that TLS))
// so if bindgen attempts to redeclare then as global statics then
// the linker will get unhappy. Access this via a wrapped static fn, see below.
.blocklist_item("...")
// ...
// Bindgen can't currently handle Atomics correctly, so blocklist everything
// from the *atomic* headers and any symbol that references atomics.
.blocklist_item(".*_atomic_.*")
.blocklist_item("...") // Contains an Atomic
// ...
// symbols that reference other blocked symbols
.blocklist_item("...")
// ...
// Big list of static functions that I haven't yet validated work.
.blocklist_item("...")
// ...
// Symbols directly defined in the Nth+1 header file that doesn't want to play nice
.blocklist_item("...")
// ...
// static inline functions would normally get compiled in, so they are not
// exported as symbols for FFI purposes. This generates small C functions
// that just immediately call the inlined functions, and links them as the
// original function name. They are not inlined in Rust unless LTO is enabled.
.wrap_static_fns(true)
// The generated C functions will go into a file in this path (with the .c ext)
.wrap_static_fns_path(output_path.clone().join("extern"))
// Tell cargo to invalidate the built crate whenever any of the included header files changed.
.parse_callbacks(Box::new(bindgen::CargoCallbacks::new()))
.generate()
.expect("Unable to generate bindings");
// Some of the doc comments have 4x leading spaces, which causes them to be interpreted
// as inline code examples. They aren't code and so doc tests fail to compile. This fixup
// replaces the leading spaces with dots.
let bindings = bindings.to_string()
.replace("/// ", "/// ....")
.replace("\\n ", "\\n ....");
The text was updated successfully, but these errors were encountered:
I'm working on using Bindgen 0.71.1 to add Rust bindings for a library with several hundred header files. The library makes extensive use of
atomic
s (which I know Bindgen won't handle) andstatic inline
functions. So far, I have not needed to directly interact with any variable or function that is or acceptsatomic
types, so I have built up an extensive block list of symbols that I know are in problematic headers, contain problematic arguments, etc.However, despite my best efforts to start small and include more headers as I go, I still find that I'm running into the following error whenever I turn on
.wrap_static_fns(true)
and include the Nth + 1 header file (either one individually is fine).The problem isn't that Bindgen can't generate bindings for the symbol -- I expect that Bindgen won't be able to handle 100% of this library. The problem is that the error gives absolutely no indication which symbol it is choking on, nor which symbol cause that symbol to be pulled into the binding list.
This user also requested a better error message for a slightly different error with the same root cause. They resolved their issue, however.
I've attempted to attach a debugger to the
build-script-build
and step through bindgen to see if I could locate the name of the symbol (or better yet, the name of at least one symbol that caused it to be added to the bindings). However, it seems all the symbols are placed into a large flat map structure and my debugger can't quite chase down through the structs to read the.name
member.For any sufficiently large library, it's intractable to build up an allow list because the transitive closure grows too quickly. At the same time, this error is preventing the use of a block list because I cannot divine which symbol to block.
An alternative to including the symbol information in the error output would be to automatically prune symbols Bindgen can't handle instead of panicking, but that's likely a much larger change.
I don't think the
build.rs
will be too helpful, as the reproduction is essentially the same as #2151, but in case it does make a difference, here's the gist of it:The text was updated successfully, but these errors were encountered: