[lldb-dev] Prebuilt binary for Windows

[Zachary Turner via lldb-dev]

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?

On Wed, Jan 11, 2017 at 3:45 PM Vadim Chugunov <vadimcn at gmail.com> wrote:

> 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.
>
> 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.
> ​
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170111/bbd5006b/attachment-0001.html>