Repository navigation
Error when building _freeze_module in current main commit. #121629
Description
Bug report
Bug description:
I have a local clone from which I run git pull on every so often and then build. However somehow this broke when I pulled today the latest commits:
posixmodule.obj : error LNK2019: unresolved external symbol _PssCaptureSnapshot referenced in function _win32_getppid [C:\python\cpython\PCbuild\_freeze_module.vcxproj]
posixmodule.obj : error LNK2019: unresolved external symbol _PssQuerySnapshot referenced in function _win32_getppid [C:\python\cpython\PCbuild\_freeze_module.vcxproj]
posixmodule.obj : error LNK2019: unresolved external symbol _PssFreeSnapshot referenced in function _win32_getppid [C:\python\cpython\PCbuild\_freeze_module.vcxproj]
C:\python\cpython\PCbuild\win32\_freeze_module.exe : fatal error LNK1120: 3 unresolved externals [C:\python\cpython\PCbuild\_freeze_module.vcxproj]
What is not helpful is when I look up those functions it does not list the *.lib file that they are defined in, but it lists that they are in kernel32.dll which means they have to be in kernel32.lib then. Issue is I thought _freeze_module already included kernel32.lib in it's project file.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Windows
Activity
AraHaan commentedon Jul 11, 2024
I looked and it does not add kernel32.lib.
AraHaan commentedon Jul 11, 2024
Ah I figured out the issue, it seems that
win32builds of_freeze_moduleare broken while amd64 ones are not.AraHaan commentedon Jul 11, 2024
I managed to fix this on the default
x64builds by replacing the$(PreferredToolArchitecture)with$(Platform)inpcbuild.proj. While it might not be the best fix in terms of what the core devs want, it at least works for me.zooba commentedon Jul 15, 2024
This seems likely to be something on your machine, possibly a bad compiler/WinSDK install.
You can also set
PreferredToolArchitecturetox64as an environment variables if you need to override the version of the compiler and libraries you are using. It's possible that whatever has gone bad for you is limited to the x86 compiler and libs.AraHaan commentedon Jul 15, 2024
Tested ARM64 build rn and that works as well. Perhaps the 32 bit libs got corrupted somehow after I upgraded the winsdk to the latest version and uninstalled the previous version on the latest VS2022 Preview update (I modified the install using the installer after it installed the update without rebooting)?
zooba commentedon Jul 16, 2024
I would gladly believe that the installer has removed files it shouldn't have! Generally VS has tests for this, but the WinSDK is a separate installer, which makes for an impossible test matrix (plus these kinds of bugs are usually in the old installer, so they still cause problems even after they've been fixed).
Might be worth finding the Windows Software Development Kit in your list of installed apps and running a Modify/Repair to see if it restores the files.
Jamlee commentedon Sep 1, 2024
same prolem too.
zooba commentedon Sep 2, 2024
Without more information about what's causing the problem (best theory right now is a corrupted 32-bit compiler installation), there's nothing we can fix.
We won't be breaking cross-compilation by changing the default value of
PreferredToolArchitecture, or by using a different value when that's the one that we mean. Users can override it as needed (as long as we don't change it).