On Sun, Oct 22, 2023 at 3:46 PM Xing Guo <higuox...@gmail.com> wrote: > Can we also check if the clang's version is compatible with llvm's version in > llvm.m4? I have multiple llvm toolchains installed on my system and I have to > specify the $CLANG and $LLVM_CONFIG variables each time I build the server > against a toolchain that is not present in $PATH. If one of the variables is > missing, the build system will pick up a default one whose version might not > be compatible with the other. E.g., If we use clang-16 and llvm-config-15, > there will be issues when creating indexes for bitcodes at the end of > installation.
Hmm. Problems that occur to me: 1. We need to decide if our rule is that clang must be <= llvm, or ==. I think this question has been left unanswered in the past when it has come up. So far I think <= would be enough to avoid the error you showed but can we find where this policy (ie especially commitments for future releases) is written down in LLVM literature? 2. Apple's clang lies about its version (I don't know the story behind that, but my wild guess is that someone from marketing wanted the compiler's version numbers to align with xcode's version numbers? they're off by 1 or something like that). Another idea could be to produce some bitcode with clang, and then check if a relevant LLVM tool can deal with it.
