[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: Fixed for 3.5.3, 3.6.1 and default. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Roundup Robot added the comment: New changeset c3da1ee47e6b by Steve Dower in branch '3.5': Issue #26071: Fixes preprocessor definition and rebuilds wininst-14.0[-amd64].exe https://hg.python.org/cpython/rev/c3da1ee47e6b New changeset 0528a6743018 by Steve Dower in branch '3.6': Issue #26071: F

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Ned Deily added the comment: Since we are two days from the final release, the fix requires rebuilding and replacing a binary file in the source repo, and you state (in related Issue28680): "Considering we've gone through all of 3.5 and 3.6 with very few people noticing (and as far as I'm awar

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: Looks like I acknowledged the error in the patch and then didn't fix it when I applied it. The change needed here is what Mark describes above, plus recompiling the executable stubs. Or alternatively, I can probably just edit out the bytes in the existing stub f

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Christoph Gohlke added the comment: The applied patch breaks bdist_wininst installers for 64-bit Python. See . -- nosy: +cgohlke ___ Python tracker __

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Roundup Robot added the comment: New changeset daa6fdaf9835 by Steve Dower in branch '3.5': Issue #26071: bdist_wininst created binaries fail to start and find 32bit Python https://hg.python.org/cpython/rev/daa6fdaf9835 New changeset db74f3a4cbeb by Steve Dower in branch 'default': Issue #26071:

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: Applied the patch and rebuilt the stubs, so this will show up in 3.5.2 and 3.6. -- assignee: -> steve.dower resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: The downside of the preprocessor - no errors when you spell an ifdef wrong ;) It looks good to me. -- ___ Python tracker ___ _

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Mark Hammond added the comment: welp, I hadn't actually tested the patch on x64 yet ;) > #ifdef WIN_64 should read: > #ifdef _WIN64 WIN_64 is a Python invented name and this stub doesn't Python pull the headers in... -- ___ Python tracker

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Mark Hammond added the comment: > > The directory of the DLL can be added to the search path if you > > use LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an > > absolute path. > That sounds like the better fix then. I thought there was something along > those lines availab

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: > The directory of the DLL can be added to the search path if you use > LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an absolute > path. That sounds like the better fix then. I thought there was something along those lines available. We al

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Eryk Sun added the comment: > why isn't the directory containing the loaded DLL searched > for dependencies? That's possible. The loader provides several ways to go about solving this problem. The directory of the DLL can be added to the search path if you use LoadLibraryEx with the flag LOAD

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: Ultimately, launching python.exe is better than loading python##.dll here because it avoids DLL planting vulnerabilities, but I'm honestly a little surprised still that LoadLibrary won't resolve vcruntime in this case. Been a while since I looked, and I haven't h

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Mark Hammond added the comment: > Mark said the "built binary links against the DLL version of the CRT > but I just checked in 3.5.1 that you actually didn't switch that > one to link against vcruntime140.dll like you did with everything else Yeah, I didn't dig too much further here, but I'm fai

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Eryk Sun added the comment: Steve, I think I understand the linking problem now -- in terms of the bad assumption I mentioned in the previous message. Mark said the "built binary links against the DLL version of the CRT", but I just checked in 3.5.1 that you actually didn't switch that one to

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Eryk Sun added the comment: > We'd have to statically link python##.dll. I was talking about the partially static build that you used for wininst-14.0-amd64.exe in rc3, in which vcruntime is linked statically but ucrt is linked dynamically (actually to the api-ms-win-crt-* API sets). But is th

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: In this case, it needs to load vcruntime for the python##.dll, so linking isn't going to make any difference. We need to statically link the loader, since it will be run independently and can't have any dependencies, but when it finds a Python install and loads t

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Eryk Sun added the comment: I would call SetDllDirectory instead of changing the current directory. This replaces the current directory in the DLL search. Then call SetDllDirectory(NULL) to restore the default before returning. When you say "the CRT assembly", you're talking about vcruntime14

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

Steve Dower added the comment: Looks good to me. Feel free to check it in, Mark, or one of us will get to it if you're not set up for committing right now. -- ___ Python tracker ___

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

New submission from Mark Hammond: Binaries created by bdist_wininst fail on 3.5+ for 2 reasons: * The built binary links against the DLL version of the CRT. This means the binary will typically fail to start as the CRT DLL isn't found. * When looking for 32bit Python versions, it fails to take