<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.  <div><br></div><div>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.</div><div><br></div><div>Does the redistributable issue present a challenge for your use case?</div></div></blockquote><div><br></div><div>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 (<a href="https://bugs.python.org/issue24872">discussion of this issue in Python bug tracker</a>).   Looks like Python folks opted for shipping VCRUNTIME140.DLL in their install directory.</div><div><br></div></div></div></div>