Bindgen build script panicking on "x86_64-unknown-linux-gnu" in debug

[almanac-problem]

Hi there,

I ran into an error while compiling rust-rocksdb, which appears to potentially be a bindgen issue. I re-created this issue on my system using the same code provided in the bindgen tutorial, but using 0.72.0 instead of 0.71. The panic occurs here:

rust-bindgen/bindgen/lib.rs

Lines 914 to 920 in b03b222

	if is_host_build {
	debug_assert_eq!(
	context.target_pointer_size(),
	size_of::<*mut ()>(),
	"{effective_target:?} {HOST_TARGET:?}"
	);
	}

In the debug profile builds, the output is:

...
Compiling bindgen_test v0.1.0 (~/projects/bindgen_test)
error: failed to run custom build command for `bindgen_test v0.1.0 ~/projects/bindgen_test)`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_DEV_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.

Caused by:
  process didn't exit successfully: `~/projects/bindgen_test/target/debug/build/bindgen_test-b821d7dddd98ba9e/build-script-build` (exit status: 101)
  --- stdout
  cargo:rustc-link-search=/path/to/lib
  cargo:rustc-link-lib=bz2
  cargo:rerun-if-env-changed=TARGET
  cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS
  cargo:rerun-if-changed=wrapper.h

  --- stderr

  thread 'main' panicked at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bindgen-0.72.0/lib.rs:917:13:
  assertion `left == right` failed: "x86_64-unknown-linux-gnu" "x86_64-unknown-linux-gnu"
    left: 4
   right: 8
  stack backtrace:
     0: __rustc::rust_begin_unwind
               at /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2/library/std/src/panicking.rs:697:5
     1: core::panicking::panic_fmt
               at /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2/library/core/src/panicking.rs:75:14
     2: core::panicking::assert_failed_inner
               at /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2/library/core/src/panicking.rs:427:23
     3: core::panicking::assert_failed
               at /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2/library/core/src/panicking.rs:387:5
     4: bindgen::Bindings::generate
     5: bindgen::Builder::generate
     6: build_script_build::main
     7: core::ops::function::FnOnce::call_once
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

As noted above, the problem seems to be that context.target_pointer_size() and size_of::<*mut ()>() are not equal even though the effective target and HOST_TARGET are the same. I would expect both to be 8. I followed the calls back to the creation of BindgenContext.translation_unit, but I know absolutely nothing about bindgen as I've yet to use it directly.

Interestingly, if I compile with --release, that debug_assert_eq is not hit and the compilation is successful. I was able to run application code which relied on rust-rocksdb --release immediately after hitting this panic with --debug.

Please let me know what additional diagnostics would be helpful. I'm running a distro derivative of Ubuntu 22.04:

[bindgen_test] uname -srv
Linux 6.5.0-45-generic #45~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC

[bindgen_test] rustc --print host-tuple 
x86_64-unknown-linux-gnu

Thanks!

[emilio]

It seems you're using a 32-bit libclang, but a 64-bit bindgen, which is probably confusing us? Or something along those lines at least. It seems clang is reporting the target pointer size to be 4 bytes, but you're in a 64-bit system so pointers should be 64-bit wide.

[almanac-problem]

Ah, finally found it. I was stumped because my system clang looked good. I finally ran BINDGEN_EXTRA_CLANG_ARGS="--verbose" cargo build -vv which showed that my Espressif clang was being invoked at some point. I was able to manually solve this by either building with BINDGEN_EXTRA_CLANG_ARGS="--target=x86_64-unknown-linux-gnu" or by removing the Espressif clang from the path.

It's interesting because it seems like information was being pulled from both clang installs during build process due to the presence of the correct target but the wrong pointer size.

assertion `left == right` failed: "x86_64-unknown-linux-gnu" "x86_64-unknown-linux-gnu"
    left: 4
   right: 8

Not sure if this is a search path difference or what. These were the two clangs:

[bindgen_test] ~/.rustup/toolchains/esp/xtensa-esp32-elf-clang/esp-19.1.2_20250225/esp-clang/bin/clang --version
Espressif clang version 19.1.2 (https://github.com/espressif/llvm-project.git esp-19.1.2_20250225)
Target: riscv32-esp-unknown-elf
Thread model: posix
InstalledDir: ~/.rustup/toolchains/esp/xtensa-esp32-elf-clang/esp-19.1.2_20250225/esp-clang/bin
[bindgen_test] /usr/bin/clang --version 
Ubuntu clang version 14.0.0-1ubuntu1.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin      

Anyway, thanks for the quick response, sorry for the setup-related issue.