Make libclang attr as optional in the rust_bindgen_toolchain #3788
Conversation
UebelAndre
left a comment
UebelAndre
left a comment
There was a problem hiding this comment.
Can you add some rationale for why?
|
I've updated the description with the rationale. LMK if you have any questions. |
UebelAndre
left a comment
UebelAndre
left a comment
There was a problem hiding this comment.
Doesn't bindgen require libclang to work at all? I'm concerned that if it's not provided by the rule then it's picked up on the host. Is this not the case?
Can you also add a test for this?
Yes, bindgen requires libclang to parse headers. However, if the bindgen binary is statically linked with libclang, it is fully self-contained and does not need to load libclang as a shared library at runtime, making the libclang attr redundant.
From the
I believe adding a test case would require setting up the build infra for a statically linked bindgen binary, which would be a significant undertaking? Do you have any suggestions on how else we might document that the libclang attribute is mandatory for dynamically linked systems? |
|
I think we should be very explicit in the docs that this is really only useful for a custom |
Why? Surely it's just a change to some
Is it possible to have a process wrapper query the bidngen binary to see if clang is either statically linked or explicitly available? |
Clarify that the libclang attribute in rust_bindgen_toolchain is only optional when the bindgen binary is statically linked. This ensures users are aware that omitting it for dynamically linked binaries may lead to non-hermetic builds by falling back to system libraries.
3 participants
The
libclangattr is currently used to set env variables for the underlyingclang-syscrate to dynamically link libclang. In build systems that use static linking, these are redundant. Making libclang attr optional simplifies the toolchain config for static linking.