Hi guys,
Can someone point me in the right direction on this . I have managed to set up my environment on windows , compiling python2.7.10 using VS2013 and building llvm/lldb in VS2013. lldb and all its libraries build successfully so its just when I import lldb into my python project I get this error.
File "<string>", line 1, in <module>
Import error: No module named embedded_interpreter
Also when I use the 'script' command in the lldb interpreter , lldb completely crashes with an unhandled exception in the python file_write function (fileobject.c:1852)
n2 = fwrite(s, 1, n, f->f_fp);
the call to fwrite causes an access violation . My intuition tells me that i'm missing a lib or something but I can't put my finger on it. Please Help !
Are you using MSBuild or Ninja to build (i.e. are you clicking the Build Solution button in Visual Studio or running ninja from command line)? I don’t know where it puts this stuff with a VS2013 build, but with a ninja build, your directory will be organized like this:
build
___bin
___lldb.exe
___liblldb.dll
___lib
___site-packages
___lldb
___lldb_d.pyd // If this is a debug build, lldb.pyd if release
I’m betting you’re missing the pyd file. Can you confirm? Then we can diagnose that if it turns out to be the problem.
A build with msbuild or from VS2013 using the .sln file produce the same directory structure.
The error looks a lot like what I see when I don’t have lldb_d.pyd set up correctly. It can’t load the lldb python module (a link to the shared library), so it gets cranky.
Was there an error in your build when it tried to run finishSwigWrapperClasses.py? That’s where the link gets set up.
No There is no error when I run finishSwigWrapperClassess but when I build the Swig_Wrapper project I get “SWIG needs to be run again” every time . which I find pretty odd.
Thanks for the response , sorry for the delay. As a matter of fact I actually got rid of the system python and installed my custom version. I do suspect it is a linking problem though. When I build liblldb.dll it always loads python27.dll instead of python27_d.dll. Do you happen to know where the python27 lib is specified as an input library because the project properties in liblldb does not specify it . however the linker complains if I don’t specify the lib directory in ‘additional directories’ and when I do it always links to the python27lib. I grepped the whole build directory and two files SystemInitializer.obj and LLDBWrapPython.obj seem to contain /DEFAULTLIB:python27.lib. Do you have an idea of what is causing the compiler to do this ?
Are you using -DCMAKE_BUILD_TYPE=Debug when you generate CMake?
Can you try to regenerate CMake with that command line and see if that helps?
Ok , I’ll do that and get back to you .
cheers,
Que
A couple of fixes to the Python/LLDB Windows build process were committed on Oct 1st, I suggest you try building a more recent revision (especially if setting CMAKE_BUILD_TYPE to Debug as suggested by Zach fixes your issue).
Hi Zachary,
Ok so I did end up reconfiguring it and rebuilding but that was no help . I then realized that I was importing python27.dll as well as python27_d.dll . When I rebuilt liblldb I started getting an single unresolved error for
imp_Py_InitModule which I guess was the symbol for the Py_InitModule4 python api which is actually a macro which is defined depending on a few flags . So I ended up rebuilding python27 and the unresolved error went away and built everything from scratch . The good news is that when I invoke the ‘script’ command in the lldb interpreter it doesn’t crash anymore and I can use the python interpreter . I can even import the lldb module without getting the embedded interpreter Import error . However I when I actually import lldb from a python module and run it with the standalone interpreter I still get the Import Error. I have checked the PYTHONPATH which was different for the lldb embedded interpreter and updated the variable to contain the missing paths but no cigar . Any suggestions ?
When you built LLDB, did you specify a -DPYTHON_HOME= on your CMake command line, and also run the install_custom_python.py script? There’s a lot of steps, so it seems like almost everybody misses at least one step when doing this.
I’m actively working (as in, literally right now) on getting LLDB to work with Python 3. If all goes smoothly, hopefully all of these problems will disappear and everything will just work without any user configuration required at all.
I’ll work my way backwards . Eventually I’ll get there. Anyway if you need any help on adding python 3 support , I’ll be more than happy to help
thanks ,
Que
I’m about 90% of the way there on the native code side. The last part is tricky, but still mechanical. After I finish that the trick is going to be getting the test suite running. I suspect that will be nasty, just because there’s a few thousand lines of code and it’s going to be a pain to find everything. Might need some help there, I’ll let you know.