On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner <ztur...@google.com> wrote:
> Ahh, that would make sense as well, since LLDB links against liblldb as a > dll. Don't see a good solution to this short of forcing dynamic linking. > liblldb has to be a dll because it needs to be visible to python as an > extension module. And if it's a dll and uses static linking, then we would > have to require that lldb.exe not pass file handles across the dll > boundary. If that's easy then great, but I suspect it probably isn't. > > Honestly dynamic linking was created to solve exactly these kinds of > problems. Yes there's the redist issue if on Windows < 10, but it seems > like a small price to pay for something that doesn't have weird subtle > bugs. And as time goes on, more and more people will be on windows 10 > anyway. > > Does the redistributable issue present a challenge for your use case? > There are actually two part of the MSVC runtime: the Universal C Runtime (UCRT) and the compiler-specific, VCRUNTIME140. The former is widely available (comes with Windows 10, and had been pushed to Vista, 7 and 8 via Windows Update). The latter is tied to the compiler version and must still be redistributed with programs. Ideally, LLDB would use dynamic UCRT + static VCRUNTIMExx. Unfortunately this doesn't seem to be a supported configuration (discussion of this issue in Python bug tracker <https://bugs.python.org/issue24872>). Looks like Python folks opted for shipping VCRUNTIME140.DLL in their install directory.
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev