Error when building _freeze_module in current main commit.

[AraHaan]

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

[AraHaan]

I looked and it does not add kernel32.lib.

[AraHaan]

Ah I figured out the issue, it seems that win32 builds of _freeze_module are broken while amd64 ones are not.

[AraHaan]

I managed to fix this on the default x64 builds by replacing the $(PreferredToolArchitecture) with $(Platform) in pcbuild.proj. While it might not be the best fix in terms of what the core devs want, it at least works for me.

[zooba]

This seems likely to be something on your machine, possibly a bad compiler/WinSDK install.

You can also set PreferredToolArchitecture to x64 as 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]

This seems likely to be something on your machine, possibly a bad compiler/WinSDK install.

You can also set PreferredToolArchitecture to x64 as 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.

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]

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.

I managed to fix this on the default x64 builds by replacing the $(PreferredToolArchitecture) with $(Platform) in pcbuild.proj. While it might not be the best fix in terms of what the core devs want, it at least works for me.

I got the same problem and this worked.

[Jamlee]

same prolem too.

[zooba]

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).