[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

[Greg Clayton via lldb-commits]

clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

I would rather not see us export everything in LLVM. The gentleman's agreement doesn't enforce anything and this will cause crashes when people try to launch a tool against a different liblldb.dylib. It will also increase the size of liblldb dramatically. We seem to worry about lldb-server being 11MB, so I can't see us being OK with liblldb increasing in size by a few hundred K. All the mangled names from all of llvm will be quite large. As soon as we do this, people might then want everything in clang, and then everything in swift. I would like to see our liblldb only export the stuff from the "lldb" namespace like it does. We guarantee the API will work with future versions of things.

One alternate solution is to have two dylibs:

- liblldbprivate
- liblldb

liblldb would remain as it is. liblldbprivate would export lldb_private::*, llvm::* and clang::*. liblldb would link against liblldbprivate, and lldb-mi would link against both. We would then need to build something extra into the tools that link againt liblldbprivate where they would check a version number to ensure they are using the correct liblldbprivate. This check would happen in liblldb during the SBDebugger::Initialize() call and it would cause the program to exit if things don't match. lldb-mi would need to do the same thing during startup and exit if things don't match. I am not too thrilled with this either as we will still have one very very large shared library in liblldbprivate since it would contain all exported symbols from lldb_private::*, llvm::* and clang::*.

I still think your other solution of statically linking in your own copy is the right thing to do.


https://reviews.llvm.org/D26188