Paolo Bonzini <pbonz...@redhat.com> writes:
> On 10/15/24 14:07, Manos Pitsidianakis wrote: >> Add stub definition of memory_order enum in wrapper.h. >> Creating Rust bindings from C code is done by passing the wrapper.h >> header to `bindgen`. This fails when library dependencies that use >> compiler headers are enabled, and the libclang that bindgen detects does >> not match the expected clang version. So far this has only been observed >> with the memory_order enum symbols from stdatomic.h. If we add the enum >> definition to wrapper.h ourselves, the error does not happen. >> Before this commit, if the mismatch happened the following error could >> come up: >> /usr/include/liburing/barrier.h:72:10: error: use of undeclared identifier >> 'memory_order_release' >> /usr/include/liburing/barrier.h:75:9: error: use of undeclared identifier >> 'memory_order_acquire' >> /usr/include/liburing/barrier.h:75:9: error: use of undeclared identifier >> 'memory_order_acquire' >> /usr/include/liburing/barrier.h:68:9: error: use of undeclared identifier >> 'memory_order_relaxed' >> /usr/include/liburing/barrier.h:65:17: error: use of undeclared >> identifier 'memory_order_relaxed' >> /usr/include/liburing/barrier.h:75:9: error: use of undeclared identifier >> 'memory_order_acquire' >> /usr/include/liburing/barrier.h:75:9: error: use of undeclared identifier >> 'memory_order_acquire' >> /usr/include/liburing/barrier.h:72:10: error: use of undeclared >> identifier 'memory_order_release' >> panicked at >> [..]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bindgen-cli-0.70.1/main.rs:45:36: >> Unable to generate bindings >> To fix this (on my system) I would have to export CLANG_PATH and >> LIBCLANG_PATH: >> export CLANG_PATH=/bin/clang-17 >> export LIBCLANG_PATH=/usr/lib/llvm-17/lib >> With these changes applied, bindgen is successful with both the >> environment variables set and unset. >> Since we're not using those symbols in the bindings (they are only used >> by dependencies) this does not affect the generated bindings in any way. > > That is still likely to break, depending on what changes in the future in the > headers that clang provides. > > We can do this (or alternatively, limit the number of files included in > wrapper.h; in this case trying to remove use of io_uring's headers from > include/block/aio.h) but probably we have to leave the warning in. > > Paolo I agree with Paolo's comments. It was reported that using inconsistent versions of clang and libclang can lead to unsound bindings even they compile. I would recommend to keep that warning till a proper resolution, e.g. clang-sys provides consistent paths, is present. -- Best Regards Junjie Mao
