The compiler redistributable is also widely available:

 

https://www.microsoft.com/en-us/download/details.aspx?id=48145

 

The python 3.5 dll would still use the runtime dll; lldb should do the same. 
I’ve had crashes in the past because lldb and python used different runtimes.

 

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Vadim 
Chugunov via lldb-dev
Sent: Wednesday, January 11, 2017 8:49 PM
To: Zachary Turner <ztur...@google.com>
Cc: LLDB <lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] Prebuilt binary for Windows

 

 

 

On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner <ztur...@google.com 
<mailto: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

Reply via email to