<div dir="ltr"><div>FWIW, Python provides <a href="https://www.python.org/dev/peps/pep-0384/" target="_blank">stable ABI</a> for a subset of their API.  <br></div><div></div><div><br></div><div>I've actually managed to create a version of LLDB that is Python-optional and Python version-agnostic (for versions 3.3 up).   Though given the number of hoops I had to jump through to get there, I cannot recommend this approach for mainline LLDB.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 22, 2019 at 9:39 AM Adrian McCarthy via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</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"><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" target="_blank">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>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>