[lldb-dev] RFC: Separation of embedded Python from the rest of LLDB.

[Ted Woodward]

It’s not just a Windows issue, the issue crops up on Linux if you’re not running LLDB on the OS/Version it was built on.

 

We build on Win 7 64, with Python 2.7.8 that I built using VS 2013, without any of the extras like SSH. We also build on SLES 11 Linux using clang 3.4 and Python 2.7.6 that I built (because of a crasher that Todd Fiala fixed on python.org, but the fix hasn’t made it into python yet). We test on Win 7 and SLES 11, Ubuntu 10 and Ubuntu 12.

 

The big question is “which version of Python am I running with?” I found that I can’t rely on the system Python on Linux, because different versions of Python don’t play well with each other. I don’t just mean the shared libraries; the modules cause big problems, even when you’re only loading modules written in Python, not .pyd libraries. LLDB built with 2.7.6 (with libpython2.7.so in ../lib) seems to be OK with Ubuntu 10’s Python 2.6 modules, but with SLES’s modules it throws lots of warnings, and with Ubuntu 12’s modules (2.7.3) it crashes. Never mind the Ubuntu 10/12 OpenSSH split (1.0 -> 1.1) which means I can’t load hashlib (loaded by default) because it loads SSL, which will fail on the wrong side of the OpenSSL divide.

 

My solution – ship a partial Python install with LLDB, and set PYTHONHOME/PYTHONPATH to point to the right place. So on Windows I ship 2.7.8 modules and on Linux I ship 2.7.6 modules with LLDB. This way I don’t care what system LLDB is run on; it just works.

 

 

Saying you can’t build Python with VS2013 isn’t true. I did. I’m having issues with some of the bindings (specifically “print lldb.debugger” gives “No value”, even though it’s there), but for the most part it works.

 

Also, you don’t always need to build 3rd party modules. Many of them are only implemented in Python, and don’t load a DLL (.pyd), so you don’t have to rebuild them.

 

--

Qualcomm Innovation Center, Inc.

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

 

From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu] On Behalf Of Reid Kleckner
Sent: Wednesday, February 25, 2015 10:59 AM
To: Vince Harron
Cc: lldb-dev at cs.uiuc.edu
Subject: Re: [lldb-dev] RFC: Separation of embedded Python from the rest of LLDB.

 

On Wed, Feb 25, 2015 at 5:58 AM, Vince Harron <vharron at google.com <mailto:vharron at google.com> > wrote:

This seems like a lot of work to support Windows users who might want to use pre-compiled python modules.

 

To me, the primary benefit is that you can build LLDB with Python support without building Python from source. More onerous, once you build Python from source, you have to maintain two separate environments: your normal development environment with normal Python on PATH, and one with LLDB's version of Python on PATH and PYTHONPATH.

 

I think we should distribute a VS2015 based version of Python 2.7 binaries and call it a day.

 

We can worry about 2020 problems in 2020.  =)

 

Reasonable people may disagree.

 

I disagree. I guess that makes me reasonable. ;)

 

The main thing for me is that once we put together a pre-built Python, the instructions to rebuild it will immediately rot. In a matter of months, some user will arrive needing LLDB and Python to be built with a different VS version, and I give it 50/50 odds that the instructions will work.

 

Personally, I think the lowest impact change for everyone not affected by this is to split the Python API code out into a shared library. LLDB has more Python source than C++ source interacting with Python. Maintaining Python source compat with 2.7 and 3.5 will be fragile and will require testing more configurations. Reducing the number of obscure ways that non-Windows developers can break the Windows build is good.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150225/bfc36043/attachment.html>