Today I fought with a buildbot all evening, because adding a -color option to llvm-cov caused it to emit the following error, only on that bot: : CommandLine Error: Option 'color' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Eventually I figured out that the bot used configure and --enable-shared, for some reason, and reproduced the failure locally. It turns out the configure build with shared creates a monolithic llvm lib and links all the tools to that, and this causes *every tool* to have *every cl::opt option* from every library in LLVM. This is pretty broken. The cmake build with BUILD_SHARED_LIBS doesn't have this problem, since it builds multiple library and only links the ones the tool asks for. I've worked around this by renaming my option for now, but that's really terrible and it makes me sad.
Yep.
This breaks the use case of LLVM_BUILD_LLVM_DYLIB=ON for lld/lldb-server at least, both fails to start with an assert due to duplicate options.
Yep... The underlying problem here is that command line options use global initializers to register themselves in the system. If you link all the LLVM libraries together you get every option. The long-term fix for this is actually something I was working on a year ago. We need to stop using static initializers to register options, and instead we need to have explicit initialization. In the short-term there are two options. (1) Rename options so that there are no conflicts, (2) Exclude libraries with option conflicts from the LLVM combined library. Option 2 would mean statically linking some LLVM content where it is needed, but should work today by using the LLVM_DYLIB_COMPONENTS CMake option.
Going to call this resolved as it deals with configure and Justin says that cmake doesn't have this problem :)
Well, cmake with BUILD_SHARED_LIBS doesn't have the problem, but you really shouldn't use that option - it has its own problems. The cmake feature that actually does something like --enable-shared did, LLVM_BUILD_LLVM_DYLIB, does exhibit this problem.
Aha. Cool.
We encountered this bug on macOS (I haven't been able to reproduce on Linux) in Rust; when Rust switched to using LLVM_LINK_LLVM_DYLIB, the rust-enabled lldb started crashing. See https://github.com/rust-lang/rust/issues/54126 One option I'm looking at is hacking our clang and lldb builds to use DISABLE_LLVM_LINK_LLVM_DYLIB everywhere. Maybe that would work. LLVM_DYLIB_COMPONENTS seems to be the official way but this seems to be hard to use in practice; AFAICT there's no way to get the list of components one might want, or what they correspond to. Nicer would be a way to say "exclude anything from clang or lldb". I wonder if there are other options available; as I'm also not too keen to carry an ad hoc patch to all the cmake files.
(In reply to Tom Tromey from comment #7) > We encountered this bug on macOS (I haven't been able to reproduce on > Linux) in Rust; when Rust switched to using LLVM_LINK_LLVM_DYLIB, > the rust-enabled lldb started crashing. This turned out to be somewhat self-induced: the installer was not preserving symlinks properly, so lldb could end up loading two copies of liblldb.dylib. This doesn't mean there is no underlying bug here though, just that I initially misdiagnosed the Rust problem.