-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Introduce llvm-enable-rtti
option
#93640
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
This option is controls when LLVM build adds `-fno-rtti`. Some details available here: https://www.llvm.org/docs/HowToSetUpLLVMStyleRTTI.html When this option is enabled, llvm build produces a bit more symbols: ```` rust % nm build/x86_64-apple-darwin/llvm/lib/libLLVMCore.a | grep llvm10CallbackVHE 0000000000007120 S __ZTIN4llvm10CallbackVHE 0000000000007240 S __ZTSN4llvm10CallbackVHE 00000000000070e8 S __ZTVN4llvm10CallbackVHE ```` and just to compare the same build without this option (current behaviour): ``` rust % nm build/x86_64-apple-darwin/llvm/lib/libLLVMCore.a | grep llvm10CallbackVHE 00000000000070b8 S __ZTVN4llvm10CallbackVHE ``` An attempt to bootstrap `rust` with `clang` which was built with enabled RTTI may fail with linking error like: ``` = note: dyld: Symbol not found: __ZTIN4llvm10CallbackVHE Referenced from: /opt/local/libexec/llvm-9.0/bin/../lib/libclang-cpp.dylib Expected in: .../build/x86_64-apple-darwin/stage2/lib/libLLVM.dylib in /opt/local/libexec/llvm-9.0/bin/../lib/libclang-cpp.dylib ```
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon. Please see the contribution instructions for more information. |
The better approach is backported to upstream as rust-lang/rust#93640
What is the exact purpose of this option? Why would someone want to enable it? |
@bjorn3 I've tried to build rustc by clang which was compiled without As soon as I added this option and enabled it to this build => it linked and works. |
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
The better approach is backported to upstream as rust-lang/rust#93640
I'm going to close this in favor of #93756. Thanks! |
The better approach is backported to upstream as rust-lang/rust#93640
This option is controls when LLVM build adds
-fno-rtti
. Some details available here: https://www.llvm.org/docs/HowToSetUpLLVMStyleRTTI.htmlWhen this option is enabled, llvm build produces a bit more symbols:
and just to compare the same build without this option (current behaviour):
An attempt to bootstrap
rust
withclang
which was built with enabled RTTI may fail with linking error like: