LLDB build searching for the wrong Python, again.

Subprojects LLDB
1

After rebasing, my local LLDB builds have again broken because it goes looking for the wrong Python DLL. I’m searching through git logs, but I’m not seeing a related change.

Does anyone know what causes CMake to get confused about which Python versions are installed?

LINK : fatal error LNK1104: cannot open file ‘python37_d.lib’

Why is it looking for 3.7? My CMake command uses every hint I know about to ensure that it finds Python 3.8:

cmake -GNinja -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON -DCMAKE_BUILD_TYPE=Debug -DLLDB_TEST_DEBUG_TEST_CRASHES=1 -DPYTHON_HOME=“C:\Program Files\Python38” -DLLDB_PYTHON_HOME=“C:\Program Files\Python38” -DPython3_ROOT_DIR=“C:\Program Files\Python38” -DPython3_FIND_REGISTRY=LAST -DLLDB_TEST_COMPILER=D:\src\llvm\build\ninja_dbg\bin\clang.exe …..\llvm-project\llvm -DLLVM_ENABLE_ZLIB=OFF -DLLVM_ENABLE_PROJECTS=“clang;lld;lldb;clang-tools-extra;compiler-rt”

My environment doesn’t reference any other version of Python:

D:\src\llvm\llvm-project>set | find /I “python”
Path=C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\bin\HostX64\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\bin\Roslyn;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Team Tools\Performance Tools\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Team Tools\Performance Tools;C:\Program Files (x86)\Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\vs2019\x64;C:\Program Files (x86)\Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\vs2019;C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64;C:\Program Files (x86)\Windows Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\Tools;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\corpam;C:\Windows\ccmsetup;C:\Program Files\Git\cmd;C:\Program Files\Git\usr\bin;D:\src\util\GnuWin32\bin;C:\Program Files\doxygen\bin;C:\Program Files\Notepad++;D:\src\llvm\build\ninja_dbg\bin;D:\src\llvm\llvm-project\clang\tools\clang-format;C:\Program Files\Python38;D:\src\llvm\llvm-project\llvm\utils\git-svn;D:\src\util;D:\src\util\swigwin-3.0.12;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja
__VSCMD_PREINIT_PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\corpam;C:\Windows\ccmsetup;C:\Program Files\Git\cmd;C:\Program Files\Git\usr\bin;D:\src\util\GnuWin32\bin;C:\Program Files\doxygen\bin;C:\Program Files\Notepad++;D:\src\llvm\build\ninja_dbg\bin;D:\src\llvm\llvm-project\clang\tools\clang-format;C:\Program Files\Python38;D:\src\llvm\llvm-project\llvm\utils\git-svn;D:\src\util;D:\src\util\swigwin-3.0.12

D:\src\llvm\llvm-project>where python
C:\Program Files\Python38\python.exe

D:\src\llvm\build\ninja_dbg>which python
/c/Program Files/Python38/python

I do not have 3.7 on my machine. For a long while now, I’ve had to keep exactly one version of Python on my machine specifically to prevent LLDB builds from trying to mix versions.

But I’m stumped once again.

Clues appreciated,
Adrian.

2

I’ve figured out some of the what but I still don’t understand the why.

I checked the Windows registry, and found some remnants referencing Python 3.6. I doubt that’s related, but I obliterated them anyway.

I scrutinized the very noisy output of Cmake and discovered two things:

  1. Cmake found my Python 3.8, right where it should be, then it said, “Could NOT find Python3 (missing: Development)”. I’m not sure why it didn’t think that version has the development files–it does.
  2. Next, Cmake found Python 3.7 buried in the Visual Studio 2019 installation tree. (I keep forgetting that VS smuggles other software onto the machine.) I have no idea HOW Cmake found this version. It’s not anywhere in the PATH. It’s not referenced by any other environment variables. If it’s referenced from the Windows registry, I couldn’t find it. It’s just magic, I guess.

So I spun up the Visual Studio Installer and removed every package that mentioned Python. I then trashed my build tree and started again.

This time, Cmake selected my Python 3.8 tree, apparently satisfied that it does indeed have the development files. (Why does the presence of an unreferenced Python 3.7 cause Cmake to think the easy-to-find 3.8 installation doesn’t have development files??? Sounds like a Cmake bug to me.)

So, for the moment, I have a working build again.

It’s interesting to note that, in the four or five times since last fall that I’ve been bit by the wrong-version-of-Python-while-building-LLDB bug, the “solution” has been different. I wonder what it’ll be next time.

Thanks to the folks who sent me advice off-list.

Adrian.