A ping for this regression - Ted Woodward seems to have had a patch for fixing broken Windows scripting support but the 5.0.0 snapshot release didn’t have the fix. Is it possible to land that patch for the next snapshot?
This is currently breaking LLDB Visual Studio Code integration on Windows (for context, see https://github.com/vadimcn/vscode-lldb/issues/37 .)
Thanks!
Jamie
Python support on Windows is much more problematic than support on something like MacOS or Linux. The python you use when you run lldb must be the same python used when you build it. Bad things happen – warnings, crashes, etc – when you use a different rev of the dll/so or the library directory (which contains dlls/sos) than what was used when building lldb. MacOS and various Linux distros ship with a fixed version of python, so lldb can be built with that version. Windows doesn’t have a default python, so you need to make sure that your user has the same version of python that lldb was built with.
For the Hexagon tools, we ship the python dll/so and the library directory that we built with. We use 3.5.1 on Windows, and 2.7.8 on Linux. On Linux, we set RPATH to …/lib, so lldb/liblldb.so can find libpython.so. On both, we set a cmake variable LLDB_DEFAULT_PYTHONHOME, and use it when initializing python to point lldb to the path where our python library is installed. This code isn’t upstreamed, but I can upstream it if the community would like it.
Another issue on Windows is the python installation integrity check in cmake/modules/LLDBConfig.cmake. It checks to see if python is installed correctly like this:
if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))
message(“Python installation is corrupt. Python support will be disabled for this build.”)
set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
return()
endif()
If you don’t have the debug version of python installed (as is the case on our builders), this check will fail, and python will be turned off. Internally, I break this check up into debug and release checks, based on the value of CMAKE_BUILD_TYPE. I also don’t check for the release dll, because our builders don’t have that. I can also upstream this if the community is interested.
Ted
This is no longer true right? That was one of the major drivers behind moving to Python 3.5. All that matters is
a) The build configuration matches (if LLDB was built against Python debug, you must have debug libraries available)
b) The architecture matches (if it’s an x64 build of LLDB, you need x64 Python libraries)
c) The version is 3.5 or higher.
Aside from that it shouldn’t matter
I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3 .so/library directory, so I’m not willing to say building on Windows with 3.6.1 and using the 3.5.2 dll/library directory will work. Python has never been very forgiving when using a different setup than what you built with.
My point with that statement is you’ve got to make sure the runtime environment matches the build environment, something harder to do on Windows where there is no default runtime environment.
Well, never prior to 3.5 anyway. That was literally one of the entire points of requiring 3.5+ on Windows. Python for Windows post 3.5 uses the Universal CRT, which is forwards compatible. More information here: http://stevedower.id.au/blog/building-for-python-3-5/
I can’t speak to the issue of 2.7.6 vs 2.7.3 on Linux you experienced, but on Windows the officially supported position of the Python project is that you can install any version of Python post 3.5 and it “just works”.
Note that building with 3.6.x and using 3.5.x won’t work, but any of 3.5.x revisions should be compatible between themselves.
This is a bit problematic setup. I would expect that the opposite
(building with version X, and running with version Y >= X) will work,
but using an older runtime version is tricky because your code may end
using symbols which are not present in the older version.
Without more information, it's hard to say whether this was a problem
in your case. It could be that python 2.7.3 simply has a bug, and the
crash would happen even if you were using the same version of python
for building (our bots are at 2.7.6, and I am not aware of anyone
testing/using/shipping lldb with an older version of python)
pl
I’m not actually too sure of the compatibility situation between Python versions, but I think forcing a user to install a Python 3.5.x version is quite reasonable for LLDB use.
I can also upstream this if the community is interested.
Ted if you have a patch to fix the scripting feature for LLDB on Windows it would be much appreciated by me and other Rust developers trying to use LLDB with Visual Studio Code.