Apologies if this is being handled in one of the other “python version/compatibility” threads or PRs.
The short of it is: Windows got a new install method (the Python Install Manager). This is supplanting the previous installer (old installers won’t be produced for python 3.16+). Crucially, the old installer had a toggle to install debug binaries. The new one does not and it doesn’t seem like they have any interest in adding an option for it.
Building LLDB currently requires python<Vers>_d.lib to build, so it is currently impossible(?) to build against a python version from the Python Install Manager. You must build Python from source or install via the old installer.
Frankly, I don’t know enough about LLDB or the Python integration to be of much help fixing this myself, but it looks like others have encountered (and solved) the same issue
I don’t see why this should be the case. For a debug build of LLDB, maybe, but even then you’re not debugging Python itself. Could be that because these _d were installed anyway, we were unknowingly relying on them.
Do you have some build logs showing this requirement being enforced?
truncated build log, compiled for release mode:
cmake -B ./build_msvc -G "Visual Studio 17" `
-DLLVM_ENABLE_PROJECTS="clang;lldb" `
-DCMAKE_BUILD_TYPE=Release `
-DZLIB_INCLUDE_DIR=C:/Users/ant_b/scoop/apps/zlib/current/include `
-DZLIB_LIBRARY=C:/Users/ant_b/scoop/apps/zlib/current/lib/zlib.lib `
-DCMAKE_EXPORT_COMPILE_COMMANDS=1 `
-DPYTHON_HOME="C:\Users\ant_b\AppData\Local\Python\pythoncore-3.14-64" `
-DLLVM_TARGETS_TO_BUILD=X86 `
-DLLVM_INCLUDE_EXAMPLES=0 `
-DLLVM_INCLUDE_TESTS=0 `
./llvm
...
cd ./build_msvc
msbuild -v:m -m llvm.sln
...
Build FAILED.
...
"C:\Coding\NotMyCode\llvm_patches\llvm-project\build_msvc\llvm.sln" (default target) (1) ->
"C:\Coding\NotMyCode\llvm_patches\llvm-project\build_msvc\ALL_BUILD.vcxproj.metaproj" (default target) (2) ->
"C:\Coding\NotMyCode\llvm_patches\llvm-project\build_msvc\tools\lldb\source\API\liblldb.vcxproj.metaproj" (default target) (736) ->
"C:\Coding\NotMyCode\llvm_patches\llvm-project\build_msvc\tools\lldb\source\API\liblldb.vcxproj" (default target) (1701) ->
(Link target) ->
LINK : fatal error LNK1104: cannot open file 'python314_d.lib' [C:\Coding\NotMyCode\llvm_patches\llvm-project\build_msvc\tools\lldb\source\API\liblldb.vcxproj]
1 Warning(s)
1 Error(s)
Within ./build_msvc/CMakeCache.txt, there’s entries:
//Path to a program.
_Python3_EXECUTABLE_DEBUG:INTERNAL=_Python3_EXECUTABLE_DEBUG-NOTFOUND
//Path to a library.
_Python3_LIBRARY_DEBUG:INTERNAL=_Python3_LIBRARY_DEBUG-NOTFOUND
//Path to a library.
_Python3_RUNTIME_LIBRARY_DEBUG:INTERNAL=_Python3_RUNTIME_LIBRARY_DEBUG-NOTFOUND
And within ./build_msvc/CMakeFiles/CMakeConfigureLog.yaml, there’s several entries similar to the following:
-
kind: "find-v1"
backtrace:
- "C:/mingw64/share/cmake-4.1/Modules/FindPython/Support.cmake:2430 (find_program)"
- "C:/mingw64/share/cmake-4.1/Modules/FindPython3.cmake:656 (include)"
- "C:/Coding/NotMyCode/llvm_patches/llvm-project/lldb/cmake/modules/FindPythonAndSwig.cmake:12 (find_package)"
- "C:/Coding/NotMyCode/llvm_patches/llvm-project/lldb/cmake/modules/FindPythonAndSwig.cmake:43 (FindPython3)"
- "C:/Coding/NotMyCode/llvm_patches/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:47 (find_package)"
- "C:/Coding/NotMyCode/llvm_patches/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:64 (add_optional_dependency)"
- "C:/Coding/NotMyCode/llvm_patches/llvm-project/lldb/CMakeLists.txt:38 (include)"
mode: "program"
variable: "_Python3_EXECUTABLE_DEBUG"
description: "Path to a program."
settings:
SearchFramework: "NEVER"
SearchAppBundle: "NEVER"
CMAKE_FIND_USE_CMAKE_PATH: true
CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH: true
CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH: true
CMAKE_FIND_USE_CMAKE_SYSTEM_PATH: true
CMAKE_FIND_USE_INSTALL_PREFIX: true
names:
- "python3.14_d"
- "python3_d"
- "python_d"
candidate_directories:
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/"
searched_directories:
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/python3.14_d.com"
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/python3.14_d.exe"
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/python3.14_d"
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/python3_d.com"
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/python3_d.exe"
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/python3_d"
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/python_d.com"
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/python_d.exe"
- "C:/Users/ant_b/AppData/Local/Python/pythoncore-3.14-64/python_d"
found: false
...
Thanks.
This is at least one of the places we reference _d:
But that shouldn’t be run in this case due to the CMAKE_BUILD_TYPE.
Could it be that this is a Visual Studio solution that includes different BUILD_TYPEs and that’s why it’s trying to find a debug library even though you’re asking for release?
(which I thought of because llvm-project/lldb/cmake/modules/FindPythonAndSwig.cmake at main · llvm/llvm-project · GitHub references MULTI_CONFIG)
I’m not familiar with msbuild, does that build command build only release, or all of them?
MSBuild builds the first target it finds, and any dependencies, unless:
And is that first target the debug variant by any chance?
If a release build fails because it can’t find the debug library, the issue is that we’re linking to the wrong library.
However, I don’t think you’re building a release build. The Visual Studio generator is a multi-config generator. It doesn’t respect CMAKE_BUILD_TYPE:
Specifies the build type on single-configuration generators (e.g. Makefile Generators or Ninja).
You’re likely building a Debug build. I don’t know how this is specified when invoking msbuild directly, but you can pass the config through CMake: cmake --build (directory) --config Release.
Not sure how well the multi-config generators work, I usually use Ninja.
Huh, that’s strange. I’ve never had an issue using CMAKE_BUILD_TYPE to toggle debug vs release before. Maybe it was the older version of VS i was using or I just got lucky or something? No idea. It does build fully when using the VS UI to force only Release mode to build.
That said, being unable to build debug LLDB without compiling CPython yourself is still an issue.
I agree, though I think the best we can do is fix that in our documentation. Potentially we could look ahead and check if the file exists but it feels like a layering violation to do that in LLDB’s CMake files.
But maybe you’re saying “shouldn’t it be technically possible to use release Python?” and that I don’t know the answer to.
We mention the old installer’s option in our docs - Building - 🐛 LLDB
We should add to that, that with the new “install manager” the only option is to build your own if you need a debug lldb. Plus a note about the msbuild pitfall.
From what I have read, it is because a debug build of lldb links to the debug C runtime (CRT). We cannot mix release and debug CRT in the same program because the debug version has changes that change its ABI.
So we link them like this:
debug lldb
| |
| \-> debug python
| |
\------\--> debug CRT
2 Likes