[lldb-dev] Prebuilt binary for Windows

[Adrian McCarthy via lldb-dev]

>  [UCRT] had been pushed to Vista, 7 and 8 via Windows Update

I didn't think that was true in general.  One of the redist options is to
include an MSU in your installer that tells Windows Update to add UCRT to
the list of components it updates.  So some Vista, 7, and 8 users may have
received it via Windows Update, but probably not all.

That's what all the deployment articles seem to suggest (assuming I've
understood them correctly).  I suppose they may have decided to ship UCRT
to pre-Windows 10 users anyway, but I haven't come across anything that
says that.

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

>
>
> On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner <zturner at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170112/34948da2/attachment.html>