On 8/30/2024 2:43 PM, Manos Pitsidianakis wrote:
🎱
On Fri, 30 Aug 2024, 04:19 Junjie Mao, <junjie....@intel.com
<mailto:junjie....@intel.com>> wrote:
On 8/28/2024 9:08 PM, Alex Bennée wrote:
> Manos Pitsidianakis <manos.pitsidiana...@linaro.org
<mailto:manos.pitsidiana...@linaro.org>> writes:
>
>> Add rust/qemu-api, which exposes rust-bindgen generated FFI bindings and
>> provides some declaration macros for symbols visible to the rest of
>> QEMU.
>
> As mentioned on IRC I'm hitting a compilation error that bisects to this
> commit:
>
>Â Â [148/1010] Generating bindings for Rust rustmod-bindgen-rust_wrapper.h
>Â Â FAILED: bindings.rs <http://bindings.rs>
>Â Â /home/alex/.cargo/bin/bindgen ../../rust/wrapper.h --output
/home/alex/lsrc/qemu.git/builds/rust/bindings.rs <http://bindings.rs>
--disable-header-comment --raw-line '// @generated' --ctypes-prefix
core::ffi --formatter rustfmt --generate-block --generate-cstr --impl-debug
--merge-extern-blocks --no-doc-comments --use-core --with-derive-default
--allowlist-file '/home/alex/lsrc/qemu.git/include/.*' --allowlist-file
'/home/alex/lsrc/qemu.git/.*' --allowlist-file
'/home/alex/lsrc/qemu.git/builds/rust/.*' -- -I/home/alex/lsrc/qemu.git/.
-I/home/alex/lsrc/qemu.git/builds/rust/. -I/home/alex/lsrc/qemu.git/include
-I/home/alex/lsrc/qemu.git/builds/rust/include -I/usr/include/capstone
-I/usr/include/p11-kit-1 -I/usr/include/pixman-1 -I/usr/include/libpng16
-I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/spice-1
-DSTRUCT_IOVEC_DEFINED -I/usr/include/libusb-1.0 -I/usr/include/SDL2
-D_REENTRANT -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/slirp
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-DNCURSES_WIDECHAR=1 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount
-I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo
-I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/x86_64-linux-gnu -I/usr/include/gio-unix-2.0
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -pthread -I/usr/include/gtk-3.0
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount
-I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo
-I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/x86_64-linux-gnu -I/usr/include/gio-unix-2.0
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -pthread
-I/usr/include/vte-2.91 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libmount
-I/usr/include/blkid -I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gtk-3.0
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu
-I/usr/include/gio-unix-2.0 -I/usr/include/atk-1.0
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include
-pthread -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/spice-server
-I/usr/include/spice-1 -I/usr/include/cacard -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/nss
-I/usr/include/nspr -I/usr/include/PCSC -pthread -D_REENTRANT
-I/usr/include/pipewire-0.3 -I/usr/include/spa-0.2 -D_REENTRANT
-I/usr/include/p11-kit-1 -I/usr/include/fuse3
-I/usr/include/x86_64-linux-gnu -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64
-D__USE_LARGEFILE64 -DUSE_POSIX_ACLS=1 -I/usr/include/uuid
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/p11-kit-1 -I/usr/include/p11-kit-1 -I/usr/include/p11-kit-1
-I/usr/include/p11-kit-1 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -std=gnu11 -MD -MQ
../../rust/wrapper.h -MF wrapper.h.d
>Â Â /usr/include/liburing.h:296:3: error: use of undeclared identifier
'memory_order_release'
>Â Â /usr/include/liburing.h:1080:11: error: use of undeclared identifier
'memory_order_acquire'
>Â Â /usr/include/liburing.h:1116:9: error: use of undeclared identifier
'memory_order_acquire'
>Â Â /usr/include/liburing.h:1125:9: error: use of undeclared identifier
'memory_order_relaxed'
>Â Â /usr/include/liburing.h:1161:2: error: use of undeclared identifier
'memory_order_relaxed'
>Â Â /usr/include/liburing.h:1197:19: error: use of undeclared identifier
'memory_order_acquire'
>Â Â /usr/include/liburing.h:1267:10: error: use of undeclared identifier
'memory_order_relaxed'
>Â Â /usr/include/liburing.h:1269:10: error: use of undeclared identifier
'memory_order_acquire'
>Â Â /usr/include/liburing.h:1320:2: error: use of undeclared identifier
'memory_order_release'
>Â Â panicked at
/home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bindgen-cli-0.69.4/main.rs:52:36:
>Â Â Unable to generate bindings:
ClangDiagnostic("/usr/include/liburing.h:296:3: error: use of undeclared
identifier 'memory_order_release'\n/usr/include/liburing.h:1080:11: error:
use of undeclared identifier
'memory_order_acquire'\n/usr/include/liburing.h:1116:9: error: use of
undeclared identifier
'memory_order_acquire'\n/usr/include/liburing.h:1125:9: error: use of
undeclared identifier
'memory_order_relaxed'\n/usr/include/liburing.h:1161:2: error: use of
undeclared identifier
'memory_order_relaxed'\n/usr/include/liburing.h:1197:19: error: use of
undeclared identifier
'memory_order_acquire'\n/usr/include/liburing.h:1267:10: error: use of
undeclared identifier
'memory_order_relaxed'\n/usr/include/liburing.h:1269:10: error: use of
undeclared identifier
'memory_order_acquire'\n/usr/include/liburing.h:1320:2: error: use of
undeclared identifier 'memory_order_release'\n")
Those missing identifiers should have been defined in stdatomic.h which is
part
of C11. You can check if that header exists under the default header search
paths (which is listed by clang -E -Wp,-v -) and whether that file declares
those enum constants. If so, you can further check whether there is any
stdatomic.h elsewhere that shadows the standard one.
Indeed. These are in the compiler's own header files. I had problems on Debian
when using clang-14 and clang-15 but I got rid of them after I upgraded to newer
versions. If anyone can confirm/reproduce this we can add a meson warning check?
I can reproduce the issue after rolling back clang-18 to clang-15, but the issue
is not tied to any specific clang version. It happens when the version of newest
libclang does not match with the "clang" executable in PATH.
The effective header search paths of libclang invoked by bindgen have the
following:
1. The default search paths used by the "clang" executable. The clang-sys crate
determines which executable to use and collects its default search paths, and
bindgen adds them (in the form of "-isystem") to clang args.
2. The default search paths that libclang has.
Clang has a version-specific standard header directory (on my Ubuntu it looks
like /usr/lib/llvm-15/lib/clang/15.0.7/include). When those versions mismatch,
the effective search paths contain two standard header paths, causing
stdatomic.h to be included twice without declaring any symbol because clang's
stdatomic.h starts with:
#ifndef __CLANG_STDATOMIC_H
#define __CLANG_STDATOMIC_H
#if __STDC_HOSTED__ && \
__has_include_next(<stdatomic.h>) && \
(!defined(_MSC_VER) || (defined(__cplusplus) && __cplusplus >= 202002L))
# include_next <stdatomic.h>
#else
(symbol declarations ...)
Both the clang executable and libclang library are detected by clang-sys at
runtime. In my experiments, that crate always find the latest libclang, but
doesn't necessarily find the latest clang when there are multiple "clang-X" but
not "clang" in the system.
How about we try bindgen on a simple header like:
#include <libatomic.h>
memory_order order;
If that fails with unknown type name 'memory_order', suggest the user to
symbolic link the latest clang executable as "clang".
---
Best Regards
Junjie Mao