[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Change by Mark Dickinson : -- nosy: -mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

STINNER Victor added the comment: The distutils bdist_wininst command has been removed in Python 3.10: see bpo-42802. -- nosy: +vstinner resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Lawrence added the comment: This is referenced from #4431 which has been closed for over six years but keeps getting comments. -- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware ___ Python tracker _

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Changes by Mark Lawrence : -- components: -Distutils2 nosy: +dstufft versions: +Python 3.4, Python 3.5 -3rd party, Python 3.2, Python 3.3 ___ Python tracker ___ _

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Almar Klein added the comment: Just checking in to point out a possible problem with the code that strips the MSVCR dependency from the embedded manifest. The used regexpr is too greedy: the first bit can trigger on an earlier "assemblyIdentity" tag, so that after the removal the manifest is n

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: Actually, I think this is OK - the reference to the "x86" is in the tests and those tests don't actually perform a build, just check the manifest is detected and stripped (ie, the test should still work fine on 64bit boxes). Ideally the test could also check a

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: ack - that is a really good point. IIRC it can be "*". I'll try and look at this over the next day or 2. -- ___ Python tracker ___

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Dickinson added the comment: Mark: Possibly a stupid question, but in your commit (see snippet below), why is the processorArchitecture hard coded to "x86"? Is it appropriate to replace this with "amd64" for 64-bit builds, or should it always be "x86"? + + + +

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Changes by Sébastien Sablé : -- nosy: +sable ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Éric Araujo added the comment: s/distutils/distutils2/ ! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Éric Araujo added the comment: To port the patch to packaging, go into your CPython 3.3 checkout and edit Lib/packaging/compiler/msvc9compiler.py (and its test :). To port the patch to distutils2, clone http://hg.python.org/distutils2/ and edit distutils/compiler/msvc9compiler.py (same :). T

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: I pushed the changes to 2.7, 3.2 and 3.3. I'm happy to help with distutils2/packaging but I'll need to do that later once I work out where to start :) Therefore I'm not yet closing this issue. -- ___ Python tracker

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Roundup Robot added the comment: New changeset fb886858024c by Mark Hammond in branch '2.7': Issue #7833: Ext. modules built using distutils on Windows no longer get a manifest http://hg.python.org/cpython/rev/fb886858024c New changeset 9caeb7215344 by Mark Hammond in branch '3.2': Issue #7833

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Éric Araujo added the comment: Looks good. Style nit: I don’t put backslashes at end-of-lines in parens (in one re.compile call you have that). Also, I use -- where I can’t use —. -- ___ Python tracker _

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: New version of the patch with the small tweaks requested plus a NEWS entry. -- Added file: http://bugs.python.org/file23400/bug-7833-tweaks-plus-news.patch ___ Python tracker ___

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Éric Araujo added the comment: > They aren't strictly private and are designed to be overridden by > subclasses OK. > I do intend forward-porting to 3.3 and also to check it is is too late > for 3.2 (a quick check before implied it might be OK, but I'm not sure) 2.7 and 3.2 are open for bug fix

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: Thanks for the review. One note: | +def manifest_setup_ldargs | I’d make all new methods private ones (i.e. leading underscore). They aren't strictly private and are designed to be overridden by subclasses (although in practice, subclassing the compiler is

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Éric Araujo added the comment: > Note the existing test doesn't actually perform a build so the new > test also doesn't, but it does check the core logic Sounds good to me. +def manifest_setup_ldargs I’d make all new methods private ones (i.e. leading underscore). > an embedded manifests T

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: My apologies Eric - I had completely overlooked those tests. Attaching a new patch with a test. Note the existing test doesn't actually perform a build so the new test also doesn't, but it does check the core logic (ie, that a manifest with only the msvcrt re

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Éric Araujo added the comment: Let me add that I don’t know the MS toolchain at all, but if you tell me what a test should do (e.g. compile a C extension, open some compiled file and look for some bytes) I can write a test. -- ___ Python tracker <

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Éric Araujo added the comment: There is a already a test for manifest things in Lib/distutils/tests/test_msvc9compiler.py, and higher-level tests for building extension modules in Lib/distutils/tests/test_build_ext.py and Lib/distutils/tests/test_install.py. -- _

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: I'm reluctant to commit to adding test infrastructure for the distutils build commands - if I've missed existing infrastructure and adding such tests would actually be relatively simple, please educate me! Or if someone else would like to help with the infrast

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

Éric Araujo added the comment: Can the patch include regression tests? -- components: +Distutils2 nosy: +alexis, eric.araujo title: Bdist_wininst installers fail to load extensions built with Issue4120 patch -> bdist_wininst installers fail to load extensions built with Issue4120 patc

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: This is biting people (including me :) so I'm going to try hard to get this fixed. One user on the python-win32 mailing list resorts to rebuilding every 3rd party module he uses with this patch to get things working again (although apps which use only builtin

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Changes by Garen : -- nosy: +Garen ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailma

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Changes by Eric Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Changes by Anton Benard : -- nosy: +abenard ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

John Cary added the comment: Just to follow up. My case is an application that is almost all statically linked, but it loads in the python library, and at runtime it needs to load the tables module, and as distributed by Python, I get the load-time error on Windows. Using Christoph Gohlke's ex

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Christoph Gohlke added the comment: Actually, PyQt4 was not a good example since it is not build using distutils. Pywin32 and wxPython extensions are the only ones on my system specifying a dependency on Common Controls or MFC. No dependencies other than CRT, MFC, and Common Controls are spec

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: I'm wondering if, in practice, extensions which need a manifest can have the manifest being generated completely by the linker - ie, I expect that in most cases where something other than the CRT or MFC is needed in the manifest, the author will want to specify

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Christoph Gohlke added the comment: The proposed patch was meant to be backwards compatible. Unconditionally removing the whole assembly/manifest from extensions could break extensions that have additional dependencies, such as MFC or Common Controls. PyQt4 extensions for example depend on Co

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: Thinking more about this, I think the approach of this patch is more complex than necessary. I think a better patch would be one which *unconditionally* removes the manifest from extension modules. For maximum flexibility though, we should probably allow a ho

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: I'm failing to get a new pywin32 out of the door due to this issue. I've spent a few hours playing with this and I think the analysis is generally correct here. The key thing is that when using distutils, the extensions end up with a manifest (albeit one with

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Koen van de Sande added the comment: issue8870 and issue8871 are not related to this one. There, the UAC elevation fails, here the issue is with the MS runtimes, elevation is working fine. -- ___ Python tracker __

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

anatoly techtonik added the comment: I see that this issue mentions --user-access-control option. Can somebody also check if issue8870 and issue8871 are related to this one? -- nosy: +techtonik ___ Python tracker

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Christoph Gohlke added the comment: The bdist_wininst and DLL build issues also exist in Python 2.7b2. A patch against svn trunk is attached. The pywin32 v214 package fails as reported earlier when built with Python 2.7b2. It installs and functions when built with this patch. -- ver

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Mark Hammond added the comment: the pywin32 DLLs have 2 heads. They are Python extension modules as well as regular DLLs. They are built by distutils and therefore have no manifests - I think many packages use distutils to build their extension modules - it is just that they usually don't h

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Christoph Gohlke added the comment: > I have some doubts about option #4: it is a very specific use case, and then > the whole benefit of issue 4120 is lost Pythoncom are pywintypes are indeed special cases: Out of the 170 DLL files in my Python site-packages directory, these seem to be the o

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Koen van de Sande added the comment: Concerning the patch: what happens when the developer already added /MANIFEST:NO to the flags, and the code deduces that MSVCR9 is the only runtime, e.g. the case where /MANIFEST:NO is in the flags twice? Does the linker handle this OK, or does there need

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Koen van de Sande added the comment: There should be no manifest embedded into wininst, because then the cases which Issue 4120 fixed (a CRT installed into a local folder, instead of system-wide, due to limited access rights), will 'break' again: the installer can then no longer work unless t

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Changes by Mark Hammond : -- nosy: +mhammond ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Christoph Gohlke added the comment: I thought one conclusion of the discussion on issue4120 was that any executable, which embeds Python and imports MSVCR9 dependent extensions, must now provide the manifest for the MSVCR9 runtimes, either embedded or as a separate file. See

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Christoph Gohlke added the comment: The last line of my previous post should actually read python.exe setup.py bdist_wininst Anyway, here are three files (also attached) that can reproduce the problem: 1) setup.py from distutils.core import setup, Extension setup(name='testpyd', scripts =

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

Martin v. Löwis added the comment: This doesn't look right. IIUC, wininst.exe loads python26.dll, which in turn loads pywintypes.dll. So it should be python26.dll which loads the CRT. IIUC, wininst.exe is linked statically, precisely to avoid a dependency on the CRT assembly. -- nosy

[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch

New submission from Christoph Gohlke : Wininst-9.0.exe and wininst-9.0-amd64.exe are missing MSVCRT90 dependencies in the embedded manifest. While testing installers of pywin32 version 214 built with Python 2.6.4 and the msvc9compiler_stripruntimes_r