<div dir="ltr">Yes, I think it's pretty reasonable to expect a specific version of Python, especially if the pre-built Python DLLs for Windows are still built with versions as old as VS 2013.  Once you get to VS 2015 or 2017, I think the compatibility improves.<div><br></div><div>Perhaps the best thing for the pre-built LLDB is to include the right Python DLL in the distro, assuming the licensing allows that.</div><div><br></div><div>The more sophisticated solutions are probably more work than is justified by the value.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 22, 2019 at 8:29 AM Ted Woodward <<a href="mailto:tedwood@quicinc.com">tedwood@quicinc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> > * Dynamically load any supported Python DLL if/when needed<br>
> That might be tricky since the different versions are not binary compatible in<br>
> general. But it is possible, as Apple folks have shown, though it amounts to<br>
> building multiple copies of ScriptInterpreterPython and then choosing the<br>
> right one at runtime.<br>
<br>
It's not just the python dll; it's the modules directory as well. My experiments with different versions of Python on Linux led me to just ship the right python with our distribution.<br>
<br>
I saw things like building with 2.7.6 but using the 2.7.3 library/modules (and vice versa) would crash, and building with 2.7.6 but running with 2.6.x seemed to be OK, mostly. On Windows, I had crashes when loading Python 2.7.8 from <a href="http://python.org" rel="noreferrer" target="_blank">python.org</a> (built with VS 2008) in lldb built with VS 2013, so you have to think about other library dependencies too.<br>
<br>
My conclusion - you MUST use the same python that lldb was built with. Period.<br>
</blockquote></div>