Skip to content

Conversation

@ttwards
Copy link

@ttwards ttwards commented Oct 13, 2025

Fix bindgen build failure caused by missing system headers by:

  • Pass CC environment variable from CMake to cargo build/doc commands
  • Dynamically detect GCC toolchain path and version from CC variable
  • Add GCC include directory to clang arguments for bindgen
  • Create dummy arm_acle.h header to avoid ARM ACLE parsing errors

The root cause was that bindgen couldn't find stddef.h and other GCC builtin headers because:

  1. CC variable was not passed to cargo, preventing toolchain detection
  2. GCC include path was not provided to clang
  3. ARM ACLE headers caused constant expression errors in bindgen

Tested on: qemu_cortex_m3, Zephyr SDK 0.17.2

Fix bindgen build failure caused by missing system headers by:

- Pass CC environment variable from CMake to cargo build/doc commands
- Dynamically detect GCC toolchain path and version from CC variable
- Add GCC include directory to clang arguments for bindgen
- Create dummy arm_acle.h header to avoid ARM ACLE parsing errors

The root cause was that bindgen couldn't find stddef.h and other GCC
builtin headers because:
1. CC variable was not passed to cargo, preventing toolchain detection
2. GCC include path was not provided to clang
3. ARM ACLE headers caused constant expression errors in bindgen

Tested on: qemu_cortex_m3, Zephyr SDK 0.17.2
Signed-off-by: ttwards <[email protected]>
.output().ok()
.and_then(|o| String::from_utf8(o.stdout).ok())
.map(|v| v.trim().to_string())
.unwrap_or("12.2.0".to_string());

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we defaulting to 12.2.0?

let wrapper_path = PathBuf::from(env::var("WRAPPER_FILE").unwrap());

// Get GCC toolchain info to find stddef.h
let cc = env::var("CC").unwrap_or_default();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I don't think it is the right thing, ever to use the gcc compiler-specific header files with the clang compiler. Clang will have it's own version of these headers. Some platforms will have clang try to figure this out, but that doesn't happen everywhere, and I'm guessing you're running into that.

It's a little weird to try to figure out the clang headers, but it ends up being something like:

RESOURCE_DIR=$(${LIBCLANG_PATH}/../bin/clang --print-resource-dir)

Then the arguments to the clang invocation need to include: nostdinc (which I think must already be the case), and then -isystem $RESOURCE_DIR/include. This should get the versions of these headers that make sense with the clang compiler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants