[lldb-dev] LLDB Windows Python Bindings
Aidan Dodds via lldb-dev
lldb-dev at lists.llvm.org
Fri Nov 20 10:05:34 PST 2015
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 <module>
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 <module>
import ctypes # Invoke Windows API for creating symlinks
File "C:\Python35\lib\ctypes\__init__.py", line 7, in <module>
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 at AIDAN-PC /c/Python27
$ python --version
Python 2.7.10
Aidan at 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
On 19/11/2015 18:01, Zachary Turner wrote:
> +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 <http://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?
>
> On Thu, Nov 19, 2015 at 8:55 AM Aidan Dodds <aidan at codeplay.com
> <mailto:aidan at codeplay.com>> wrote:
>
> Hi Zachary,
>
> I am currently trying to produce a windows build of LLDB that has
> python
> bindings.
> There seems to be a lot of discussion on the mailing list regarding
> python at the moment.
>
> I couldn't see any documentation or instructions anywhere about how to
> produce them.
>
> I have tried with python2.7 and 3.5 varying degrees of success.
> While I was able to produce a debug version of the 2.7 interpreter,
> CMake seems to be looking for
> python27_d+.lib, and I am not sure why the + has been appended.
> My build using python 3.5 fails on finish_swig, with: ImportError: No
> module named '_ctypes'.
>
> It would be very much appreciated if you could point me to a reference
> for building the bindings
> on windows or even just give me some direction to the simplest way to
> produce them.
>
> Also out of interest what is that state of the lldb test suite on
> windows?
>
> Thanks,
> Aidan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151120/5031fbe1/attachment-0001.html>
More information about the lldb-dev
mailing list