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

Reply via email to