This RFC suggests to sync the Python versions we use to build lldb on Windows to 3.11.
Context
Python.org does not ship an official installer for ARM64 Windows before Python 3.11. Therefore, the ARM64 windows build release of lldb requires Python 3.11. The x64 build however, requires Python 3.10.
Proposal
I propose that on Windows, we bump x64 lldb’s Python dependency to Python 3.11 in order to sync the x64 and ARM64 Python requirements.
The Python dependency is a long standing issue in lldb, especially on Windows, which does not have Python installed by default. I think having 2 different required versions based on the architecture makes it even more confusing for users who might be looking for a solution on Github.
It would also simplify the documentation.
Finally, Python 3.10 is EOL in October 2026.
Since Python 3.11 is already the required version on ARM64, it is already used by lldb users. Bumping from 3.10 to 3.11 should be a low risk operation.
I’m not sure I follow the reasoning here. Our stated minimum is 3.8 (Building - 🐛 LLDB). The fact that Windows on Arm uses 3.11 isn’t in itself a problem in that sense unless you want a 3.11 only feature.
It is news to me that Windows x64 requires 3.10. I assume this happened organically?
So:
I’m not happy that Windows drifted, but it’s probably too late to fix.
Aligning all Windows to 3.11 is sensible if we accept said drift.
I’d rather have one minimum version across all platforms.
In the meantime we can reflect the apparent reality and document that there are 2 different minimums.
One of my takeaways from [RFC] Upgrading LLVM’s minimum required Python version was that for projects with more extensive use of Python, having a unique minimum would be ok. So we could decide to break from llvm overall.
Which is a bigger proposal to handle, so perhaps you’d prefer to go with “Document the reality of building on Windows”
I tried out the 21.x x86 Windows build a couple of months ago, to see how upstream handled Python on Windows. As background, downstream we’ve shipped LLDB in a Windows toolchain with Python for many years - currently 3.11.4.
My issue with the upstream Windows release is that it requires a certain version of Python (3.10.x for x86), but this is not documented anywhere, and there are no installation instructions. I’m familiar with building LLDB with Python, so I could figure out what it was looking for and where to put it, but we really need some installation instructions from the person who builds the Windows release.
lldb on Windows requires Python 3.8+ to build, just like other platforms.
The official releases on Github are built with 3.10 (x64) and 3.11 (arm64), meaning that a user has to install Python 3.10 (on x64) or 3.11 (on arm64) to be able to use lldb once installed.
Python 3.10 (and 3.11 on arm64) is an installation requirement (not a build requirement) which stems from the way we build lldb for the official releases. lldb tries to load python310.dll because we build with Python 3.10. If we were building with Python 3.8, lldb would try to load python38.dll and that would work fine.
My proposal is about building with the same versions of Python on x64 and ARM64 Windows (Python 3.11), so that the installation requirements are the same for users who download the Github release of lldb. This proposal is not about changing the Python 3.8+ build requirement of lldb.
I should have made this clearer in the original RFC!
I think that the GUI installer should be the only thing the user needs to run to install the llvm toolchain.
Additionally, lldb is (I think) the only project with an external dependency (Python).
Finally, on most platforms (except Windows), Python is already installed, meaning it does not have to be installed.
For all of these reasons, I think no one wrote instructions on how to install lldb on Windows.
https://github.com/llvm/llvm-project/pull/164893 should help with this issue. It would still be good to have install instructions, but I’m not sure where to put them to ensure the users see them.
I had a little trouble updating to a newer version on the GitHub runners, because the build system was having trouble finding the stable python dll, but I can try again.
Got it. Yes I took a broad reading of the original proposal as “build” as in “build as a matter of project policy” rather than specifically the build artifacts that we provide.
Understanding that, I agree with your proposal. Though many people could figure it out from the error messages I’m sure, removing friction is always good if we can.
I thought we could add a message to the installer like “some LLVM tools use Python and you may need to install that manually”. However, they’d still need to run the tool to find the version to install, so tbh, it’s probably better not to confuse those that do read that message, and the rest of the people will ignore it (no shade on them, I would too).
Side idea: do you think it’s worth adding a section to Troubleshooting - 🐛 LLDB about the error messages people might get and how to address them? Even if it’s just showing examples, that’s something a search engine can find.
And because you have delay loading on Windows, the error message could link to that page if you like.
Is there a config file somewhere where we set the version of Python that is used on Windows to build the toolchain? Or is that up to the contributor who builds and uploads the release?
Side idea: do you think it’s worth adding a section to Troubleshooting - 🐛 LLDB about the error messages people might get and how to address them? Even if it’s just showing examples, that’s something a search engine can find.
I think that would be great. It would make a lot of sense for the python issue. We already have something similar with the bug report url as well.
