[Lldb-commits] [PATCH] D26190: [RFC] Solve linking inconsistency, proposal two

[Pavel Labath via lldb-commits]

labath added a comment.

In https://reviews.llvm.org/D26190#584933, @mehdi_amini wrote:

> OK!
>
> How is it different from the other proposal? In the other proposal, using a LLVM class in the API boundary would break the same way under the same conditions, or did I miss something?


In the other proposal, the user would not need to include his own copy of llvm, as he could use the one that is already contained in liblldb. Everything would work fine and you could pass objects around freely (except on windows, apparently). What would *not* work is if the user upgraded liblldb, but did not recompile the client (e.g. lldb-mi, or xcode), in this case he would probably get errors at load time due to mismatched symbols.

> Something that isn't clear to me with this proposal, is how a user supposed to include its own copy of LLVM? Let say I write a client code that link to libLLVM.so and libLLDB.so?

We are assuming static linking everywhere. liblldb includes a static copy of llvm libraries, and the "user" could do the same.

In case LLVM itself is a shared library and both liblldb and lldb-mi link to it dynamically (-DLLVM_LINK_LLVM_DYLIB)  getting a second copy is hard or impossible, but then it does not really matter, as all references will be resolved correctly and uniquely. Everything should work fine as long as you don't actually *depend* on having a separate copy of llvm (which is pretty pointless as it does not have global state (apart from the crazy cl globals)). So, what we are talking about here actually is whether liblldb should re-export llvm interfaces when it has a static copy of it.

Does that make sense?


https://reviews.llvm.org/D26190