Bindings generated different from those included. #12
Comments
|
99% sure it's picking up your hosts sysroot instead of the ESP32's one because it removes all symbols like |
|
I tried to re-generate the binding in WSL. It wasn't smooth since I had to bump bindgen to 0.66.1 (because of some libclang problems in the WSL installation - i.e. my libclang was "too new"). Then I had to adapt a few things in the code since bindgen now uses usize where it used u32 before. Nothing too dramatic - just annoying. In the end it was all fine! There are definitely difference because of the different bindgen version but more like usize vs u32 and docs. Given your diff it definitely picks up headers from your host's sysroot as it seems. Do you have env-vars like I think we should at some point bump the bindgen version but apparently, it's not causing your problems - so maybe one step after another |
The format macro for the sysroot argument returns the following: C_INCLUDE_PATH is also not set on my machine. The type ones seem to be some upgrade / optimization, but yeah, some header ones are clearly missing when they shouldn't. |
|
Really weird. Maybe it helps to set the clang target to riscv32imc like here: rust-lang/rust-bindgen#1229 (comment) ? |
|
I've opened #15, sorry it's a bit noisy, but it attempts to bring most of the bindings and compilation into the Rust xtask. This doesn't solve the original issue, but I think the fix could be implemented in this PR, if we end up finding what the bug is.
This doesn't seem to fix the issue on my side. |
|
After thinking about it I think my testing on WSL in #12 (comment) wasn't really a good test since I had to update the Other than that, I think there are ways on Linux to monitor which files get opened by a process - maybe that would at least help to see which header files it picks up on your system |
|
Updating Using #15, my clang args are: Looking at strace during the binding generation, the only Which clang should it be using, actually? EDIT: I've added the bindgens preprocessed input dump ( It is very noisy, but I believe if you generate a bindgen input dump on your side, and then diff on it, that could possibly highlight where the issue is at. |
|
Ah I already see it, I guess. It's picking up headers from Maybe you have some of these env variables set? Do you have |
|
When I set Updated version of bindgen will produce the same error. |
|
Really strange. I also lied about LIBCLANG on Windows. While the variable is not set, it's on my PATH: But it doesn't change anything since I just tested on WSL with |
|
It's weird, it's not picking up my sysroot in my case. Even when I set it in clang. Tree of my sysroot. It looks like we have different content.: |
|
Oh, that's the solution! Seems clang doesn't see the expected directory structure and instead of giving an error it uses a different sysroot. For me it looks like this |
|
So this ended up being the sysroot, that wasn't the right directory. I've found the following paths on my system that when used as the sysroot with provide the same bindings as upstream:
I believe I should be taking the one from the toolchain for best compatibility. |
|
Not sure if this is still an issue or not, but the compilation and headers changed when adding hardware accelerated modular exponentiation and switching over to clang in #24, so I will close this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I try to generate bindings on a clean repo, using the following command:
cargo +stable run --manifest-path ./xtask/Cargo.tomlI get the following bindings diffs:
Additional information
clang
mbedtls
Toolchains
Stable:
esp:
The text was updated successfully, but these errors were encountered: