Issue 7020: regression in pywin32 build due to 2.6.3rc1 (original) (raw)

Created on 2009-09-30 02:20 by srid, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
zop2-build-failure.txt srid,2009-10-01 16:43
Messages (11)
msg93341 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-09-30 02:20
Today's 2.6.3rc1 introduced an regression in building pywin32. Peruse the following error: ========================================================= creating build\lib.win32-2.6\pywin32_system32 C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:E:\apy\py263\build\py2_6_3rc1-win32-x86-apy26-rrun\python\libs /LIBPATH:E:\apy\py263\build\py2_6_3rc1-win32-x86-apy26-rrun\python\PCbuild /LIBPATH:build\temp.win32-2.6\Release "/LIBPATH:C:\Program Files\Microsoft SDKs\Windows\v6.0\lib" advapi32.lib user32.lib ole32.lib oleaut32.lib /EXPORT:initpywintypes build\temp.win32-2.6\Release\win32\src\PyACL.obj build\temp.win32-2.6\Release\win32\src\PyDEVMODE.obj build\temp.win32-2.6\Release\win32\src\PyHANDLE.obj build\temp.win32-2.6\Release\win32\src\PyIID.obj build\temp.win32-2.6\Release\win32\src\PyLARGE_INTEGER.obj build\temp.win32-2.6\Release\win32\src\PyOVERLAPPED.obj build\temp.win32-2.6\Release\win32\src\PySECURITY_ATTRIBUTES.obj build\temp.win32-2.6\Release\win32\src\PySECURITY_DESCRIPTOR.obj build\temp.win32-2.6\Release\win32\src\PySID.obj build\temp.win32-2.6\Release\win32\src\PyTime.obj build\temp.win32-2.6\Release\win32\src\PyUnicode.obj build\temp.win32-2.6\Release\win32\src\PyWAVEFORMATEX.obj build\temp.win32-2.6\Release\win32\src\PyWinTypesmodule.obj /OUT:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd /IMPLIB:build\temp.win32-2.6\Release\win32\src\pywintypes.lib /MANIFESTFILE:build\temp.win32-2.6\Release\win32\src\pywintypes.pyd.manifest /MACHINE:x86 /BASE:0x1e7d0000 /DEBUG /PDB:build\temp.win32-2.6\Release\pywintypes.pdb Creating library build\temp.win32-2.6\Release\win32\src\pywintypes.lib and object build\temp.win32-2.6\Release\win32\src\pywintypes.exp C:\Program Files\Microsoft SDKs\Windows\v6.0\bin\mt.exe -nologo -manifest build\temp.win32-2.6\Release\win32\src\pywintypes.pyd.manifest -outputresource:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd;2 Unable to import verstamp, no version info will be added error: can't copy 'build\temp.win32-2.6\Release\win32\src\pywintypes26.lib': doesn't exist or not a regular file ========================================================= With 2.6.2 .. this error did not happen. The file build\temp.win32-2.6\Release\win32\src\pywintypes.lib exists (but without the version number). Was something substantial changed in distutils? (I am currently investigating this issue; more details will follow)
msg93342 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-09-30 02:21
Note the line: /OUT:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd In 2.6.2, it was: /OUT:build\lib.win32-2.6\pywin32_system32\pywintypes26.dll
msg93348 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2009-09-30 04:40
Is this a release blocker problem for 2.6.3?
msg93350 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-09-30 06:19
Quite note: I am able to repro this freshly using pywin32 212 version. http://sourceforge.net/projects/pywin32/files/pywin32/Build%20212/ pywin32-212.zip/download (214 goes past the copying part, but I could not complete the build to some missing executable in Visual C++ installation .. will verify tomorrow).
msg93351 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-09-30 06:24
Replacing the distutils packages with the Lib/distutils from 2.6.2 fixed the issue. So this was introduced by a change in distutils. Tarek, any insight into this issue?
msg93353 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-09-30 09:23
I am investingating in py2exe build_ext custom command and in the distutils bugfixes that where done, to understand the problem, I'll let you know as soon as I've found it.
msg93355 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-09-30 10:22
Pywin32 is patching "build_ext.get_ext_filename", making the assumption that it will be called only in a certain way (namespaces names) by "build_ext.build_extension", to force the name of the output from "pywintypes.pyd" to "pywintypes.dll". But this API, even if its doctest doesn't make it clear (I will change it to make it clearer) is used for both namespaced names and non namespaced names by the community. Lately we had a bug with inplace building of namespaced and non namespaced extensions. To fix it, "build_ext.build_extension" is now calling "get_ext_filename" differently and when it calls the pywin32 patched version, it fails because pywin32 fails to recognize the "pywintypes" name and pass it to the non-patched build_ext.get_ext_filename, leading to the problem. The fix has to be done on pywin32 side, by making "get_ext_filename" works as it is supposed : returning an extension name for any filename, wheter it's namespaced or not. I can help on it, it's a very simple fix. But at the end, if pywin32 has to do such patches, there's a problem in the way distutils plays with the MSVC linker : we should be able to work with .dll's and .pyd's whithout having to patch build_ext behavior like this.
msg93371 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-09-30 19:20
Thank you Tarek. I was able to fix the issue by patching pywin32's setup.py by using the `get_ext_filename` function from the CVS HEAD revision (which handles non- namespaced extensions as well).
msg93413 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-10-01 16:43
Apparently Zope2 build fails for the same reason on 2.6.3rc1 (I'm attaching the log file) File "c:\python26\lib\distutils\command\build_ext.py", line 633, in get_ext_fullpath filename = self.get_ext_filename(modpath[-1]) File "c:\python26\lib\site-packages\setuptools-0.6c9-py2.6.egg \setuptools\command\build_ext.py", line 85, in get_ext_filename KeyError: 'cAccessControl'
msg93414 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-10-01 16:53
Its a setuptools bug. That's because it uses Setuptools, which patches Distutils behavior, as soon as you "import setuptools". Matthias Klose and I have fixed this flaw in debian, and it is also fixed in Distribute, but not in Setuptools.
msg93415 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-10-01 17:03
Tarek was referring to this bug - http://bitbucket.org/tarek/distribute/ issue/41/ - above.
History
Date User Action Args
2022-04-11 14:56:53 admin set github: 51269
2009-10-01 17:03:48 srid set messages: +
2009-10-01 16:53:37 tarek set messages: +
2009-10-01 16:43:24 srid set files: + zop2-build-failure.txtmessages: +
2009-09-30 19:20:40 srid set status: open -> closedmessages: +
2009-09-30 10:22:40 tarek set resolution: accepted -> not a bugmessages: +
2009-09-30 09:23:17 tarek set resolution: acceptedmessages: +
2009-09-30 09:00:30 eric.smith set nosy: + eric.smith
2009-09-30 06:24:22 srid set messages: +
2009-09-30 06:19:24 srid set messages: +
2009-09-30 04:40:40 ned.deily set nosy: + barry, ned.deilymessages: +
2009-09-30 02:21:29 srid set messages: +
2009-09-30 02:20:31 srid create