LLDB Windows Python Bindings

+lldb-dev since this could be useful to other people.

I’m actively working on getting Python 3.5 support working. If you want to go this route, it will make your life much easier. But I don’t have a fully passing test suite yet, there are still about 30 failing tests. So consider Python 3.5 experimental, and at your own risk. (Patches welcome!)

If you want to go with Python 2.7 then the test suite should pass fully, but there are 1-2 flaky timeouts that happen occasionally. But it is a lot more work to set up and nobody ever gets it right because it’s so complicated.

So, for Python 3.5:

  1. You must use Visual Studio 2015. 2013 or earlier will not work.
  2. Install Python 3.5 from python.org
  3. Run CMake with -DPYTHON_HOME=C:\Python35
  4. That’s it. You’re done.

You don’t need to build your own Python 3.5, which it sounds like what you’re doing. If you’re not trying to build your own Python 3.5, then check to make sure your PYTHONPATH is not set to anything. Mixed environments could be a problem. If that doesn’t fix it, then debugging into it a little bit could help. For example, try running C:\Python35\python_d.exe and then typing “import _ctypes”. It should work. If you’re doing a release build then try making sure that finish_swig is running python.exe, and if you’re doing a debug build then try making sure that finish_swig is running python_d.exe.

For Python 2.7

  1. You must not be using Visual Studio 2015. Only 2013 will work
  2. Can you tell me what command line you’re invoking CMake with?
  3. Can you open up build.ninja and search for this line:

Custom command for tools\lldb\CMakeFiles\finish_swig

And then paste the line under it back into this email?

-old list
+new list

Why can’t we use VS 2015 with Python 2.7?

Python 2.7 literally does not even compile with VS 2015, you would have to fork it and fix the compilation errors. I’ve tried to upstream fixes and they won’t accept them, since 2.7 is “dead” except for maintenance and security fixes.

First off thanks for opening that up to the mailing list, it will be good if discussion of this is useful to others.

From the python 3.5 case:
I’m not using ninja.build, but instead just compiling from the visual studio ide. However, the custom build step I think you were referring to for finish_swig seems to be:

setlocal
“C:\Program Files (x86)\CMake\bin\cmake.exe” -E copy C:\Python35\python35.dll D:\rs_project\rs_llvm_build$(Configuration)\bin
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd

The exact error message for building finish_swig was the following:

------ Build started: Project: finish_swig, Configuration: Debug x64 ------
Build started 20/11/2015 17:27:07.
InitializeBuildStatus:
Touching “x64\Debug\finish_swig\finish_swig.tlog\unsuccessfulbuild”.
CustomBuild:
Python script sym-linking LLDB Python API
Traceback (most recent call last):
File “D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py”, line 383, in
main(sys.argv[1:])
File “D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py”, line 326, in main
nResult, strMsg = run_post_process_for_each_script_supported(dictArgs)
File “D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py”, line 281, in run_post_process_for_each_script_supported
vDictArgs)
File “D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py”, line 223, in run_post_process
module = import(strModuleName)
File “d:\rs_project\rs_llvm\tools\lldb\scripts\python\finishSwigPythonLLDB.py”, line 42, in
import ctypes # Invoke Windows API for creating symlinks
File “C:\Python35\lib\ctypes_init_.py”, line 7, in
from _ctypes import Union, Structure, Array
ImportError: No module named ‘_ctypes’

For the python 2.7 case:

The error I see in CMake is the following:

– Found Python version 2.7.10+

Unable to find C:/Python27/libs/python27+_d.lib

Unable to find C:/Python27/libs/python27+.lib

Unable to find C:/Python27/python27+_d.dll

Unable to find C:/Python27/python27+.dll

Python installation is corrupt. Python support will be disabled for this build.

I’m not sure where the + comes from however…

Aidan@AIDAN-PC /c/Python27
$ python --version
Python 2.7.10

Aidan@AIDAN-PC /c/Python27
$ python_d --version
Python 2.7.10

As for the CMake options its again complicated because I’m using cmake-gui.
Hopefully the relevant params are:

PYTHON_EXCUTABLE = c:/python27/python_d.exe
PYTHON_HOME = c:/python27
LLDB_DISABLE_PYTHON = False
LLDB_RELOCATABLE_PYTHON = False
SWIG_DIR = d:/swig/lib
SWIG_EXECUTABLE = d:/swig/swig.exe
SWIG_VERSION = 3.0.5

I am using Visual Studio 2013 and doing an x86_64 build.
I compiled the python interpreter with the same version also.

Its not a requirement for me to custom python for any reason, I just remember there being issues with using the release package.

Thanks,
Aidan

First off thanks for opening that up to the mailing list, it will be good if discussion of this is useful to others.

From the python 3.5 case:
I’m not using ninja.build, but instead just compiling from the visual studio ide. However, the custom build step I think you were referring to for finish_swig seems to be:

setlocal
“C:\Program Files (x86)\CMake\bin\cmake.exe” -E copy C:\Python35\python35.dll D:\rs_project\rs_llvm_build$(Configuration)\bin
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd

The exact error message for building finish_swig was the following:

------ Build started: Project: finish_swig, Configuration: Debug x64 ------
Build started 20/11/2015 17:27:07.
InitializeBuildStatus:
Touching “x64\Debug\finish_swig\finish_swig.tlog\unsuccessfulbuild”.
CustomBuild:
Python script sym-linking LLDB Python API
Traceback (most recent call last):
File “D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py”, line 383, in
main(sys.argv[1:])
File “D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py”, line 326, in main
nResult, strMsg = run_post_process_for_each_script_supported(dictArgs)
File “D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py”, line 281, in run_post_process_for_each_script_supported
vDictArgs)
File “D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py”, line 223, in run_post_process
module = import(strModuleName)
File “d:\rs_project\rs_llvm\tools\lldb\scripts\python\finishSwigPythonLLDB.py”, line 42, in
import ctypes # Invoke Windows API for creating symlinks
File “C:\Python35\lib\ctypes_init_.py”, line 7, in
from _ctypes import Union, Structure, Array

ImportError: No module named ‘_ctypes’

Looks like this is an x64 build of LLDB, so it would need to be an x64 installation of Python 3.5 To be honest I haven’t tested Python 3.5 with x64, so I’m not sure what kind of issues might arise. What happens if you run C:\Python35\python_d.exe and then write “import ctypes”. Does it work?

For the python 2.7 case:

The error I see in CMake is the following:

– Found Python version 2.7.10+

Unable to find C:/Python27/libs/python27+_d.lib

Unable to find C:/Python27/libs/python27+.lib

Unable to find C:/Python27/python27+_d.dll

Unable to find C:/Python27/python27+.dll

Python installation is corrupt. Python support will be disabled for this build.

Yea, I’m honestly not sure either. I think you will need to do some CMake debugging to figure this out. Usually what I do is crack open the CMake scripts and add some calls to the message() function at various points, to see if you can figure out where this + is coming from.

I’m not sure where the + comes from however…

Aidan@AIDAN-PC /c/Python27
$ python --version
Python 2.7.10

Aidan@AIDAN-PC /c/Python27
$ python_d --version
Python 2.7.10

This makes me think your’e using cygwin. This isn’t explicitly unsupported, but also I don’t know of anyone else Windows using cygwin, so I can’t guarantee there are no problems on the CMake side for cygwin users. If you do find some though, feel free to fix.

As for the CMake options its again complicated because I’m using cmake-gui.
Hopefully the relevant params are:

PYTHON_EXCUTABLE = c:/python27/python_d.exe
PYTHON_HOME = c:/python27
LLDB_DISABLE_PYTHON = False
LLDB_RELOCATABLE_PYTHON = False
SWIG_DIR = d:/swig/lib
SWIG_EXECUTABLE = d:/swig/swig.exe
SWIG_VERSION = 3.0.5

I am using Visual Studio 2013 and doing an x86_64 build.
I compiled the python interpreter with the same version also.

Its not a requirement for me to custom python for any reason, I just remember there being issues with using the release package.

Yea, what makes 2.7 so bad. If you want to run the test suite, you have to have a custom interpreter. And then all the difficulty that goes along with that.