<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><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 11, 2017 at 3:45 PM Vadim Chugunov <<a href="mailto:vadimcn@gmail.com">vadimcn@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Okay, as far as I can see, the issue is not with Python, but that lldb.exe and liblldb.dll have their own private copies of the CRT.<div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg">When startup script is given on the command line, lldb.exe creates a pipe, writes the script into the write end, wraps a stdio file around the read end, and gives the resulting FILE* to SBDebugger::SetInputFileHandle().  Unfortunately, since SBDebugger lives in liblldb.dll, with its own copy of the CRT, that handle is not valid there.  Later, it tries to read from that handle, and... boom.</div></div>​</div>
</blockquote></div>