Conversation
Unrelated trouble with earlier Debian versions that's not this PR's faultTesters on not-perfectly-recent Debian beware that the change to LLVM 15 that requires this (the StringLiteral::StringKind renaming) came in quite late in the LLVM release process. Users of Debian experimental will find that the new version will not build on some versions of llvm-15-dev, but that the current master does work. This is no fault of this PR, but of the Debian package claiming something to be -15 when it doesn't have all of -15's changes (but to be fair, it is an experimental pre-release, and needs to be opted in to). With the very latest experimental release (llvm-15 1:15.0.1-1~exp2 from Debian, including mlir-15-tools, and a bunch of packages the build process will conveniently ask for), this passes compilation, but fails at link time: I think this would be resolved by not only linking in libclangSema.a but also libclangSupport.a, but I don't know where that's stated (yet?). |
|
... and I have a patch: diff --git a/c2rust-ast-exporter/build.rs b/c2rust-ast-exporter/build.rs
index 4dd17e88..22581b66 100644
--- a/c2rust-ast-exporter/build.rs
+++ b/c2rust-ast-exporter/build.rs
@@ -172,6 +172,7 @@ fn build_native(llvm_info: &LLVMInfo) {
"clangParse",
"clangSerialization",
"clangSema",
+ "clangSupport",
"clangEdit",
"clangAnalysis",
"clangDriver",(Can't test whether that needs version sensing to decide whether or not to add that, as I don't want to shuffle around all my local packages once more -- I trust CI would give clear indications here) [edit: With that patch, this branch not only builds but passes all my application tests so far, except where there are other open PRs] |
60e9104 to
cadf395
Compare
|
Thanks @chrysn, I've incorporated your suggestion. Let me know if you hit any other issues. |
5b7ac17 to
95b62c3
Compare
clang::StringLiteral::StringKind::Ascii was renamed to clang::StringLiteral::StringKind::Ordinary. Add release keys and update build_translator.py. Closes #676.
96e50cb to
eae47ac
Compare
The static libraries for the homebrew version of clang/LLVM 15 are build with a feature (opaque pointers) not understood by earlier versions of clang/LLVM. Switching to dynamic linking on MacOS sidesteps the issue. We still link against static libraries if this is requested via the `llvm-static` feature flag.
Disable support for iOS in compiler-rt. Don't pass --wildcard to tar since the version shipping with MacOS doesn't support it.
eae47ac to
b2b8b13
Compare
| def llvm_major_ver_ge(test_ver) -> bool: | ||
| (major, _, _) = self.LLVM_VER.split(".") | ||
| return int(major) >= test_ver |
There was a problem hiding this comment.
I think llvm_major_ver() -> int would be better, and do the >= at call site. It's much easier to read and more flexible, and test_ver isn't otherwise used in llvm_major_ver_ge.
| if llvm_info.llvm_major_version >= 15 { | ||
| // insert after clangSema | ||
| let sema_pos = clang_libs.iter().position(|&r| r == "clangSema").unwrap(); | ||
| clang_libs.insert(sema_pos + 1, "clangSupport"); | ||
| } |
There was a problem hiding this comment.
I would put this inline as something like if llvm_info.llvm_major_version >= 15 { "clangSupport" } else { "" } and then filter out "". It's much cleaner, easier to understand the order of libraries, and more extensible if we need to add conditional libraries where order matters.
| if cfg!(feature = "llvm-static") { | ||
| false | ||
| } else { | ||
| true |
There was a problem hiding this comment.
Do we not need to do a similar libclang_path.exists() check for macOS like we do for linux?
clang::StringLiteral::StringKind::Asciiwas renamed toclang::StringLiteral::StringKind::Ordinary. Add release keys and updatebuild_translator.py. Closes #676.