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 rust-lang/rust#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.

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.

mentioned in issue llvm/llvm-bugzilla-archive#30587