Pyrex 0.9.6.4, bzr.dev revno.3763, Python 2.5.2:
There is warning C4007: 'WinMain' : must be '__stdcall'
It seems like some headers should be included in proper order.
Log of python setup.py build_ext:
running build_ext
pyrexc bzrlib/_btree_serializer_c.pyx --> bzrlib/_btree_serializer_c.c
building 'bzrlib._btree_serializer_c' extension
creating build\temp.win32-2.5
creating build\temp.win32-2.5\Release
creating build\temp.win32-2.5\Release\bzrlib
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\Python\2.5.1\include -IC:\Python\2.5.1\PC /Tcbzrlib/_btree_serializer_c.c /Fobuild\temp.win32-2.5\Release\bzrlib/_btree_serializer_c.obj
_btree_serializer_c.c
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(1579) : warning C4007: 'WinMain' : must be '__stdcall'
creating build\lib.win32-2.5
creating build\lib.win32-2.5\bzrlib
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python\2.5.1\libs /LIBPATH:C:\Python\2.5.1\PCBuild /EXPORT:init_btree_serializer_c build\temp.win32-2.5\Release\bzrlib/_btree_serializer_c.obj /OUT:build\lib.win32-2.5\bzrlib\_btree_serializer_c.pyd /IMPLIB:build\temp.win32-2.5\Release\bzrlib\_btree_serializer_c.lib
Creating library build\temp.win32-2.5\Release\bzrlib\_btree_serializer_c.lib and object build\temp.win32-2.5\Release\bzrlib\_btree_serializer_c.exp
pyrexc bzrlib/_knit_load_data_c.pyx --> bzrlib/_knit_load_data_c.c
building 'bzrlib._knit_load_data_c' extension
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\Python\2.5.1\include -IC:\Python\2.5.1\PC /Tcbzrlib/_knit_load_data_c.c /Fobuild\temp.win32-2.5\Release\bzrlib/_knit_load_data_c.obj
_knit_load_data_c.c
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python\2.5.1\libs /LIBPATH:C:\Python\2.5.1\PCBuild /EXPORT:init_knit_load_data_c build\temp.win32-2.5\Release\bzrlib/_knit_load_data_c.obj /OUT:build\lib.win32-2.5\bzrlib\_knit_load_data_c.pyd /IMPLIB:build\temp.win32-2.5\Release\bzrlib\_knit_load_data_c.lib
Creating library build\temp.win32-2.5\Release\bzrlib\_knit_load_data_c.lib and object build\temp.win32-2.5\Release\bzrlib\_knit_load_data_c.exp
pyrexc bzrlib/_dirstate_helpers_c.pyx --> bzrlib/_dirstate_helpers_c.c
building 'bzrlib._dirstate_helpers_c' extension
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\Python\2.5.1\include -IC:\Python\2.5.1\PC /Tcbzrlib/_dirstate_helpers_c.c /Fobuild\temp.win32-2.5\Release\bzrlib/_dirstate_helpers_c.obj
_dirstate_helpers_c.c
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(1579) : warning C4007: 'WinMain' : must be '__stdcall'
...
Oh, it's a known Pyrex bug.
Workaround is the same as I do for walkdirs_win32: define macros WIN32.
Here the patch:
--- setup.py 2008-10-02 15:36:12 +0000
+++ setup.py 2008-10-03 09:59:46 +0000
@@ -226,18 +226,21 @@
-add_pyrex_
add_pyrex_
if sys.platform == 'win32':
- add_pyrex_
- libraries=
- )
# pyrex uses the macro WIN32 to detect the platform, even though it should
# be using something like _WIN32 or MS_WINDOWS, oh well, we can give it the
# right value.
+ add_pyrex_
+ define_
+ add_pyrex_
+ libraries=
+ define_
+ )
add_
else:
+ add_pyrex_
if have_pyrex and pyrex_version == '0.9.4.1':
# Pyrex 0.9.4.1 fails to compile this extension correctly
# The code it generates re-uses a "local" pointer and