Meinersbur requested changes to this revision. Meinersbur added a comment. The description of `LLVM_LINK_LLVM_DYLIB` reads:
> Link tools against the libllvm dynamic library that is, its intend is what this patch would disable (for dynamic modules). I assume that you would like lldb-server to work that way even if `LLVM_LINK_LLVM_DYLIB=ON`. I suggest to document instead that lldb-server depends on dynamic objects in that configuration and therefore cannot be moved to other computer as stand-alone; their architecture might mismatch anyway. Other solutions I can think of: - The LLVM modules don't depend on libraries themselves, only the tools (opt, clang, ...) link against libllvm (note that this probably has a large impact on the build system) - Like llvm-tblgen, clang-tblgen with `LLVM_OPTIMIZED_TABLEGEN` and cross-compilation, use a sub-buildsystem that builds lldb-server with the right options (and the right target architecture) For the Polly part, you cannot just remove the `BUILD_SHARED_LIBS` condition. It will cause Polly to have the same problem of multiple command-line registrations you are observing when using `-load LLVMPolly.so`. However, I already suggested a redesign of that part in https://reviews.llvm.org/D24442. Repository: rL LLVM https://reviews.llvm.org/D24863 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
