Python 3.6 End of Life

[astrelsky]

The Windows Release build are still being linked directly to Python 3.6 which reached it's end of life on December 23, 2021. It should be built with Py_LIMITED_API set to the lowest supported version or built with the latest and greatest.

Users shouldn't have to choose between installing an ancient version of python or building lldb from source just to use lldb. It also makes users more inclined to use an old version of python since it is much faster and easier to install an old version than it is to build lldb from source.

I'm aware this issue has been raised before and this will likely be closed. However, "...yell loud enough and somebody will eventually come over to see what all the fuss is about... not that they will actually do anything about it..."

Also as you can see here the tests on windows are being run with a build of lldb using python 3.10.1. Running the tests on one version and releasing a build with a much older one is not wise.

[llvmbot]

@llvm/issue-subscribers-lldb

[JDevlieghere]

I don't think we've shipped prebuilt binaries for LLDB in a long time. Can you elaborate on what the "Windows Release build" is that you're referring to?

[astrelsky]

I don't think we've shipped prebuilt binaries for LLDB in a long time. Can you elaborate on what the "Windows Release build" is that you're referring to?

I'm referring to what comes with the Windows llvm installers.

https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.1/LLVM-13.0.1-win64.exe

[JDevlieghere]

@tstellar do you know who builds the Windows installer?

[tstellar]

@JDevlieghere It's @zmodem .

[zmodem]

I'll try to look into this today. If it works, I'll use Python 3.10.1 going forward.

[astrelsky]

I'll try to look into this today. If it works, I'll use Python 3.10.1 going forward.

What if the user has 3.9 installed? That doesn't actually solve anything. On windows for it to link to the installed version of python it needs to be compiled with PY_LIMITED_API which will result in it being linked to python3.dll instead of python310.dll.

https://docs.python.org/3/c-api/stable.html#stable-application-binary-interface

[zmodem]

I'll try to look into this today. If it works, I'll use Python 3.10.1 going forward.

What if the user has 3.9 installed? That doesn't actually solve anything. On windows for it to link to the installed version of python it needs to be compiled with PY_LIMITED_API which will result in it being linked to python3.dll instead of python310.dll.

https://docs.python.org/3/c-api/stable.html#stable-application-binary-interface

It seems to me the right place to set Py_LIMITED_API would be in the CMake files, so patches welcome.

I can't find any notes on this, but I seem to recall previous discussions about this concluding that LLDB uses more than what's available in the Limited API, so I'm not sure the flag would actually work.

[labath]

I can't find any notes on this, but I seem to recall previous discussions about this concluding that LLDB uses more than what's available in the Limited API, so I'm not sure the flag would actually work.

Yes, I'd be surprised if it was simple as setting a cmake flag. LLDB does some fairly weird stuff with python so, I don't know whether it's even technically feasible to restrict ourselves to that, but in either case, someone with an interest in supporting this would have to step up and drive this effort.

Shiping lldb built with a non-EOLed python should be fairly easy, and definitely an improvement over the current situation.

Technically, it should also be possible to also ship python inside the lldb package, so that the user does not have to find a matching python version, but I don't know if that's something we are allowed (or want) to do.