-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3.11 build failure on Win10: new _freeze_module changes? #90375
Comments
Installed 3.11.0a3 was built Dec 8 2021, 22:56:33. My corresponding repository build is a bit older than that. Rebuilding now I get I have likely seen this before today but mistook the error message for a warning and did not check the respository build date. 3.9 and 3.10 just update normally, so unique to 3.11 and apparently new freeze changes. |
The flag is not for Win8.1 and available starting in Win10 1703 with v10.0.15021 SDK. |
Good catch. We still support 8.1 for this release, so that flag will have to be taken out (and hopefully people won't be impacted by long path names here). |
With just PATHCCH_ALLOW_LONG_PATHS, PathCchCombineEx() returns a long path as a normal path (i.e. not a \\?\ extended path) if long-path support is enabled for the current process. Otherwise, if long-path support isn't enabled or available, as is always the case in Windows 8.1, then PATHCCH_ALLOW_LONG_PATHS makes PathCchCombineEx() return a long path as an extended path. In most cases, extended paths work fine. A common exception is that extended paths aren't supported for the working directory. In Windows 10+, PATHCCH_FORCE_ENABLE_LONG_NAME_PROCESS forces PathCchCombineEx() to always return a long path as a normal path, even if long-path support is disabled for the current process. For most cases, this option pretty much guarantees that long paths will cause immediate failures if long-path support is disabled for the current process. In some cases one might want an immediate failure, instead of messing around with extended paths that might fail in some obscure, buggy way. Also, for pure path manipulation one may not care whether the current process can access the path without the \\?\ prefix. |
Let me be clearer. This bug prevents me from building main (3.11) to test anything with a proper up-to-date 3.11 binary. So to me this is highest priority. Is this just my machine or every Windows system? How are CI and buildbots rebuilding and running? Is there some workaround I need to add? Use newer VC (and change devguide)? |
Only a newer WinSDK, which is not in any way a significant change to the resulting build and so isn't part of the "spec" as it were. But we'll remove the use of this flag once someone has the time to make a PR. (Remember to add the RM when you declare something a release blocker or the release may not be blocked.) |
Terry, it's just a simple bug that slipped by. The PATHCCH_OPTIONS enum in the SDK header "PathCch.h" unconditionally defines all of the options. So there's no compiler error when building with a newer version of the SDK, even though we define _WIN32_WINNT to 0x602 (Windows 8). |
Thank you. Compiles without even any warnings. Tests also all pass. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: