Re: [lldb-dev] Prebuilt binary for Windows

2017-01-19 Thread Vadim Chugunov via lldb-dev
I don't know an easy way to accomplish that. While app-local deployment is now supported, the set of deployed dlls depends on the host OS version (according to this ). I've opened a bug

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-12 Thread Reid Kleckner via lldb-dev
On Thu, Jan 12, 2017 at 10:18 AM, Vadim Chugunov via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I was referring to this: https://support.microsoft.com/en-us/help/ > 2999226/update-for-universal-c-runtime-in-windows. Granted, it was > probably marked as non-critical, so some users may have

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-12 Thread Nico Weber via lldb-dev
On Thu, Jan 12, 2017 at 1:18 PM, Vadim Chugunov via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I was referring to this: https://support.microsoft.com/en-us/help/ > 2999226/update-for-universal-c-runtime-in-windows. Granted, it was > probably marked as non-critical, so some users may have

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-12 Thread Vadim Chugunov via lldb-dev
I was referring to this: https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows. Granted, it was probably marked as non-critical, so some users may have skipped it. > One of the redist options is to include an MSU in your installer that tells Windows Update

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-12 Thread 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

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-12 Thread Ted Woodward via lldb-dev
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,

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Vadim Chugunov via lldb-dev
On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner 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

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread 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

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Vadim Chugunov via lldb-dev
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

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Zachary Turner via lldb-dev
On Wed, Jan 11, 2017 at 1:47 PM Vadim Chugunov wrote: > > Definitely seems CRT / Python related. The call to fgets indicates that > it's doing something involving a FILE*. It's probably a FILE* that refers > to a file created from within Python's copy of the CRT. > > Any

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Zachary Turner via lldb-dev
Definitely seems CRT / Python related. The call to fgets indicates that it's doing something involving a FILE*. It's probably a FILE* that refers to a file created from within Python's copy of the CRT. Another problem that dynamic linking would solve. Can you confirm that the problem does not

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Vadim Chugunov via lldb-dev
BTW, here's the call stack at the point of failure. I don't see anything Python-related in it, so maybe it's some other CRT interaction. liblldb!_invoke_watson(wchar_t * expression = 0x "", wchar_t * function_name = 0x "", wchar_t * file_name = 0x "", unsigned int

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Zachary Turner via lldb-dev
If we do that though, we still get 2 copies of the CRT. One for python and one for LLDB. While I *think* there is a strong enough API boundary in how the application and Python access each others' data structures that it doesn't matter, I'm not 100% sure without further research. It seems safer

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Reid Kleckner via lldb-dev
The purpose of linking the CRT statically was to ensure that clang can run on systems that don't have the CRT already installed from some other app or by VS itself. As long as that is preserved, feel free to do whatever you need. I think we still want to link vcruntime140 statically and the C++

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Zachary Turner via lldb-dev
Is static CRT even still supported / recommended when using the new Universal CRT? My understanding is the new UCRT is considered a core windows component, so we don't ahve to distribute redistributables anymore. Maybe I'm wrong about this. That said, I think we want dynamic regardless,

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Vadim Chugunov via lldb-dev
Sorry, just found another problem: the installed lldb crashes when given a script via the command line. For example, `lldb -O "p 42"` dies with exception 0xC409. It didn't happen with the one I've build locally, so I started digging... The difference seems to be that

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-11 Thread Hans Wennborg via lldb-dev
Great! Thanks for pushing this. On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov wrote: > Yes, the new build works! > > On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg wrote: >> >> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454). >> Please

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-10 Thread Vadim Chugunov via lldb-dev
Yes, the new build works! On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg wrote: > I've downgraded my swig to 3.0.8 and built a new snapshot (r291454). > Please let me know if that works. > > On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner > wrote: > > It

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-10 Thread Hans Wennborg via lldb-dev
I've downgraded my swig to 3.0.8 and built a new snapshot (r291454). Please let me know if that works. On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner wrote: > It sounds like the solution to the problem is to downgrade SWIG on the build > machine. If it's using version

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-10 Thread Zachary Turner via lldb-dev
It sounds like the solution to the problem is to downgrade SWIG on the build machine. If it's using version 3.0.9 or higher, just use whatever the last version before that is. 3.0.8, for example. At least there's a good workaround in the interim (i.e. setting PYTHONPATH) On Tue, Jan 10, 2017

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-10 Thread Hans Wennborg via lldb-dev
I'll do another snapshot maybe next week or the week after. You can also ping me if you want it sooner or later. We're kicking off the release process for 4.0.0 on Thursday. I don't fully understand the problem here, but if there's some way to work around it and get lldb into good shape for the

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-09 Thread Vadim Chugunov via lldb-dev
This appears to be a SWIG bug: https://github.com/swig/swig/issues/769 On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov wrote: > It worked! > > ...but not before I set PYTHONPATH=C:\Program Files > (x86)\LLVM\lib\site-packages\lldb > Without that, it couldn't find the _lldb

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-09 Thread Vadim Chugunov via lldb-dev
It worked! ...but not before I set PYTHONPATH=C:\Program Files (x86)\LLVM\lib\site-packages\lldb Without that, it couldn't find the _lldb module, so we are not quite out of the woods yet. When are you planning to make the next snapshot build? Thanks! On Mon, Jan 9, 2017 at 3:48 PM, Hans

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-09 Thread Hans Wennborg via lldb-dev
Vadim, it looks like your change was committed in r291291, and I've built a new snapshot today which includes it. Can you give it a try and see if everything works? Cheers, Hans On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner wrote: > I will commit it, in the meantime can

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-05 Thread Zachary Turner via lldb-dev
I will commit it, in the meantime can you request commit access so that any future patches you can commit? On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov wrote: > Thanks! > > Would anyone be so kind to commit that? > > On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-04 Thread Vadim Chugunov via lldb-dev
Thanks! Would anyone be so kind to commit that? On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner wrote: > Sorry, a combination of national holidays and extended vacations happened > and this fell off my radar. lgtm > > On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov

Re: [lldb-dev] Prebuilt binary for Windows

2017-01-04 Thread Zachary Turner via lldb-dev
Sorry, a combination of national holidays and extended vacations happened and this fell off my radar. lgtm On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov wrote: > Zachary, > Can you please take a look at that change? ( > https://reviews.llvm.org/D27476) > > It'll be sad if

[lldb-dev] Prebuilt binary for Windows

2017-01-04 Thread Vadim Chugunov via lldb-dev
Zachary, Can you please take a look at that change? (https://reviews.llvm.org/D27476) It'll be sad if another snapshot build gets published with broken lldb. :( On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov wrote: > This seems to work: https://reviews.llvm.org/D27476 > >