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@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
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 <ai...@codeplay.com
<mailto:ai...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
