Re: [PATCH] rust/wrapper.h: define memory_order enum

[Paolo Bonzini <pbonzini@redhat.com>]

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