[lldb] Deploy Python DLL on Windows

[Nerixyz]

f0248ca initially added a post build event to copy the Python DLL to the bin directory. This relied on PYTHON_DLL being present, which was removed in 2046d72, which moved to FindPython3.

CMake's FindPython3 sets Python3_RUNTIME_LIBRARY (https://github.com/Kitware/CMake/blob/1cd89e65d76339e6be23fc9bb0d417655a9c06ea/Modules/FindPython/Support.cmake#L3866-L3873) even though it's not documented. This is used to deploy the python3{version}(_d).dll.
I wasn't sure what the correct way to specify the destination path is. From CMake's documentation, it seemed like TYPE BIN would do the correct thing (i.e. deploy it to the bin directory), but I don't know all the customization points - maybe this should be LLVM_TOOLS_INSTALL_DIR(?).

It would be great if someone else could test this locally. Building LLDB (e.g. ninja lldb) should have python3{version}(_d).dll show up in the bin build directory and a cmake --install <build-directory> --component lldb should install the DLL to <install-prefix>/bin.

I don't know how the prebuilt binaries are built, but I'd guess they will install and zip the install-directory. In that case, this should work.

Related issues:

• [Windows] lldb fails to start (missing python36.dll) #43432
• lldb binary does not launch on Windows #47381
• on windows, missing file for lldb #53646
• Official packaging for Windows do not include Python dependencies for lldb #58095
• [lldb, Windows 11] LLDB executable crashes on every invocation #59524
• Missing Python DLL in Windows binary #74073
• windows: lldb-dap doesnt start, is missing python310.dll #85764

I hope all of them are fixed by this PR (but that depends on how the prebuilt binaries are built).

[llvmbot]

@llvm/pr-subscribers-lldb

Author: nerix (Nerixyz)

Changes

f0248ca initially added a post build event to copy the Python DLL to the bin directory. This relied on PYTHON_DLL being present, which was removed in 2046d72, which moved to FindPython3.

CMake's FindPython3 sets Python3_RUNTIME_LIBRARY (https://github.com/Kitware/CMake/blob/1cd89e65d76339e6be23fc9bb0d417655a9c06ea/Modules/FindPython/Support.cmake#L3866-L3873) even though it's not documented. This is used to deploy the python3{version}(_d).dll.
I wasn't sure what the correct way to specify the destination path is. From CMake's documentation, it seemed like TYPE BIN would do the correct thing (i.e. deploy it to the bin directory), but I don't know all the customization points - maybe this should be LLVM_TOOLS_INSTALL_DIR(?).

It would be great if someone else could test this locally. Building LLDB (e.g. ninja lldb) should have python3{version}(_d).dll show up in the bin build directory and a cmake --install <build-directory> --component lldb should install the DLL to <install-prefix>/bin.

I don't know how the prebuilt binaries are built, but I'd guess they will install and zip the install-directory. In that case, this should work.

Related issues:

• [Windows] lldb fails to start (missing python36.dll) #43432
• lldb binary does not launch on Windows #47381
• on windows, missing file for lldb #53646
• Official packaging for Windows do not include Python dependencies for lldb #58095
• [lldb, Windows 11] LLDB executable crashes on every invocation #59524
• Missing Python DLL in Windows binary #74073
• windows: lldb-dap doesnt start, is missing python310.dll #85764

I hope all of them are fixed by this PR (but that depends on how the prebuilt binaries are built).

---

Full diff: https://github.com/llvm/llvm-project/pull/137467.diff

1 Files Affected:

• (modified) lldb/bindings/python/CMakeLists.txt (+9-4)

diff --git a/lldb/bindings/python/CMakeLists.txt b/lldb/bindings/python/CMakeLists.txt
index 69306a384e0b1..0b26d3e849914 100644
--- a/lldb/bindings/python/CMakeLists.txt
+++ b/lldb/bindings/python/CMakeLists.txt
@@ -183,16 +183,21 @@ function(finish_swig_python swig_target lldb_python_bindings_dir lldb_python_tar
                              DEPENDS ${python_scripts_target})
   endif()
 
-  # Add a Post-Build Event to copy the custom Python DLL to the lldb binaries dir so that Windows can find it when launching
-  # lldb.exe or any other executables that were linked with liblldb.
-  if (WIN32 AND NOT "${PYTHON_DLL}" STREQUAL "")
+  # Copy the custom Python DLL to the lldb binary dir so that Windows can find it when launching
+  # lldb.exe or any other executables that were linked with liblldb (both during development and when installing).
+  if (WIN32 AND NOT "${Python3_RUNTIME_LIBRARY}" STREQUAL "")
     # When using the Visual Studio CMake generator the lldb binaries end up in Release/bin, Debug/bin etc.
     file(TO_NATIVE_PATH "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin" LLDB_BIN_DIR)
-    file(TO_NATIVE_PATH "${PYTHON_DLL}" PYTHON_DLL_NATIVE_PATH)
+    file(TO_NATIVE_PATH "${Python3_RUNTIME_LIBRARY}" PYTHON_DLL_NATIVE_PATH)
     add_custom_command(
       TARGET ${swig_target}
       POST_BUILD
       COMMAND ${CMAKE_COMMAND} -E copy ${PYTHON_DLL_NATIVE_PATH} ${LLDB_BIN_DIR} VERBATIM
       COMMENT "Copying Python DLL to LLDB binaries directory.")
+    install(
+      FILES "${Python3_RUNTIME_LIBRARY}"
+      TYPE BIN
+      COMPONENT lldb
+    )
   endif()
 endfunction()

[DavidSpickett]

I don't know how the prebuilt binaries are built, but I'd guess they will install and zip the install-directory. In that case, this should work.

@omjavaid would know this for Windows on Arm.

[Nerixyz]

Ping - would be great if the prebuilt binaries for the next release could include the python DLL.

[mstorsjo]

I don't know how the prebuilt binaries are built, but I'd guess they will install and zip the install-directory.

Not quite; see https://github.com/llvm/llvm-project/blob/main/llvm/utils/release/build_llvm_release.bat.

[zmodem]

I don't know who maintains lldb on windows these days. I just package it.

(Note that we don't even run the tests as part of release packaging. I've never been able to make them pass, but when I tried to remove lldb from the installer, people complained.)

Also, are those python dlls distributable, or would there be licensing implications form including them in the installer?

[Nerixyz]

Not quite; see main/llvm/utils/release/build_llvm_release.bat.

CPack should be fine. If I remember correctly, then it should install all files to a temporary directory and package that.

Also, are those python dlls distributable, or would there be licensing implications form including them in the installer?

I'm not an expert. From https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq and https://docs.python.org/3/license.html, it looks like it's okay to include this in the installer, but "You must retain all copyright notices found in the code you are redistributing".

[Nerixyz]

Closing this in favor of #151617 - see https://discourse.llvm.org/t/a-minimal-python-install-for-lldb/88658 for more context.

This PR was incomplete in that it didn't include a standard library. Since #162509, LLDB will print a proper error that it can't find Python. The current plan is to include a minimal installation of Python with LLDB. Once LLDB uses the stable Python API, it can link to python3.dll instead of python3xx.dll, meaning it should be able to pick up a system installation of Python.