Skip to content
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.

Sign up for GitHub

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

Jump to bottom

3.11 build failure on Win10: new _freeze_module changes? #90375

Closed
terryjreedy opened this issue Jan 1, 2022 · 9 comments
Closed

3.11 build failure on Win10: new _freeze_module changes? #90375

terryjreedy opened this issue Jan 1, 2022 · 9 comments
Labels
3.11 only security fixes build The build process and cross-build OS-windows release-blocker

Comments

@terryjreedy
Copy link
Member

BPO 46217
Nosy @terryjreedy, @pfmoore, @tjguk, @zware, @eryksun, @zooba, @corona10, @pablogsal, @neonene
PRs
  • bpo-46217: Revert use of Windows constant that is newer than what we support #30473
    		•

    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:

    assignee = None
closed_at = <Date 2022-01-08.00:07:13.159>
created_at = <Date 2022-01-01.01:28:36.253>
labels = ['build', 'release-blocker', 'OS-windows', '3.11']
title = '3.11 build failure on Win10: new _freeze_module changes?'
updated_at = <Date 2022-01-08.00:42:37.855>
user = 'https://github.com/terryjreedy'

    bugs.python.org fields:

    activity = <Date 2022-01-08.00:42:37.855>
actor = 'terry.reedy'
assignee = 'none'
closed = True
closed_date = <Date 2022-01-08.00:07:13.159>
closer = 'steve.dower'
components = ['Build', 'Windows']
creation = <Date 2022-01-01.01:28:36.253>
creator = 'terry.reedy'
dependencies = []
files = []
hgrepos = []
issue_num = 46217
keywords = ['patch']
message_count = 9.0
messages = ['409445', '409456', '409595', '409597', '409993', '410016', '410021', '410058', '410063']
nosy_count = 9.0
nosy_names = ['terry.reedy', 'paul.moore', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'corona10', 'pablogsal', 'neonene']
pr_nums = ['30473']
priority = 'release blocker'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue46217'
versions = ['Python 3.11']
    @terryjreedy
    Copy link
    Member Author

    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
    fileutils.c
    ..\Python\fileutils.c(2132): error C2065: 'PATHCCH_FORCE_ENABLE_LONG_NAME_PROCE
    SS': undeclared identifier [f:\dev\3x\PCbuild\_freeze_module.vcxproj]

    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.

    @terryjreedy terryjreedy added 3.11 only security fixes build The build process and cross-build OS-windows labels Jan 1, 2022
    @neonene
    Copy link
    Mannequin

    neonene mannequin commented Jan 1, 2022

    The flag is not for Win8.1 and available starting in Win10 1703 with v10.0.15021 SDK.

    @zooba
    Copy link
    Member

    zooba commented Jan 3, 2022

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

    @eryksun
    Copy link
    Contributor

    eryksun commented Jan 3, 2022

    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.

    @terryjreedy
    Copy link
    Member Author

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

    @terryjreedy terryjreedy added release-blocker build The build process and cross-build labels Jan 7, 2022
    @zooba
    Copy link
    Member

    zooba commented Jan 7, 2022

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

    @eryksun
    Copy link
    Contributor

    eryksun commented Jan 7, 2022

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

    @zooba
    Copy link
    Member

    zooba commented Jan 8, 2022

    New changeset d81182b by Steve Dower in branch 'main':
    bpo-46217: Revert use of Windows constant that is newer than what we support (GH-30473)
    d81182b

    @zooba zooba closed this as completed Jan 8, 2022
    @zooba zooba closed this as completed Jan 8, 2022
    @terryjreedy
    Copy link
    Member Author

    Thank you. Compiles without even any warnings. Tests also all pass.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    3.11 only security fixes build The build process and cross-build OS-windows release-blocker
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @eryksun @zooba @terryjreedy