While running: > python setup.py build --compiler=mingw32 on a windows XP machine, cairo installed and mingw32 installed, I get the following error: cairo >= 1.8.8 detected creating pycairo.pc creating src/config.h running build running build_ext building 'cairo._cairo' extension creating build creating build\temp.win32-2.6 creating build\temp.win32-2.6\Release creating build\temp.win32-2.6\Release\src c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Ic:/gtk/include/cairo -Ic:/gtk/ include/freetype2 -Ic:/gtk/include -Ic:/gtk/include/libpng12 -IC:\PortablePython _1.1_py2.6.1\App\include -IC:\PortablePython_1.1_py2.6.1\App\include\Stackless - IC:\PortablePython_1.1_py2.6.1\App\PC -c src/cairomodule.c -o build\temp.win32-2 .6\Release\src\cairomodule.o c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Ic:/gtk/include/cairo -Ic:/gtk/ include/freetype2 -Ic:/gtk/include -Ic:/gtk/include/libpng12 -IC:\PortablePython _1.1_py2.6.1\App\include -IC:\PortablePython_1.1_py2.6.1\App\include\Stackless - IC:\PortablePython_1.1_py2.6.1\App\PC -c src/context.c -o build\temp.win32-2.6\R elease\src\context.o src/context.c:1433: error: initializer element is not constant src/context.c:1433: error: (near initialization for `PycairoContext_Type.tp_base ') --------------------------------------------------------------------------- SystemExit Traceback (most recent call last) C:\PortablePython_1.1_py2.6.1\pycairo\pycairo-1.8.8\setup.py in <module>() 107 ext_modules = [cairo], 108 data_files=[('include/pycairo',['src/pycairo.h']), --> 109 ('lib/pkgconfig',[pkgconfig_file])], 110 ) 111 C:\PortablePython_1.1_py2.6.1\App\lib\distutils\core.pyc in setup(**attrs) 167 raise 168 else: --> 169 raise SystemExit, "error: " + str(msg) 170 171 return dist SystemExit: error: command 'gcc' failed with exit status 1
What pycairo and mingw32 versions are you using?
(In reply to comment #1) > What pycairo and mingw32 versions are you using? > pycairo 1.8.8 MinGW 5.1.6 For the record, pycairo 1.8.4 did install.
What is the gcc version ?
also in cygwin 1.7 git master gcc 4.3.4 context.c:1433: error: initializer element is not constant context.c:1433: error: (near initialization for `PycairoContext_Type.tp_base') font.c:134: error: initializer element is not constant font.c:134: error: (near initialization for `PycairoFontFace_Type.tp_base') font.c:413: error: initializer element is not constant font.c:413: error: (near initialization for `PycairoScaledFont_Type.tp_base') font.c:598: error: initializer element is not constant font.c:598: error: (near initialization for `PycairoFontOptions_Type.tp_base') path.c:209: error: initializer element is not constant path.c:209: error: (near initialization for `PycairoPath_Type.tp_base') pattern.c:197: error: initializer element is not constant pattern.c:197: error: (near initialization for `PycairoPattern_Type.tp_base') matrix.c:335: error: initializer element is not constant matrix.c:335: error: (near initialization for `PycairoMatrix_Type.tp_base') surface.c:373: error: initializer element is not constant surface.c:373: error: (near initialization for `PycairoSurface_Type.tp_base')
looks like commit 3925911c9975e148999df9dd0b8106e315e38f15 is the culprit moved and removed some stuff, including a comment - /* initialise 'tp_base' here to work round problem with MinGW compiler */
Paul, the commit makes pycairo consistent with C extension module code in Python. I would be interested to find out how cygwin (and MinGW) work round exactly the same problem in Python.
Just to add another data point to this as I have recently been building updated PyGTK installers for windows. My successful journey is described here https://bugzilla.gnome.org/show_bug.cgi?id=589671 I just added the following comment on that bug. I just built a working pycairo installer for pycairo-1.8.6. I also fixed the pkg-config file so the hack mentioned earlier re: adjusting the prefix is no longer needed. http://www.johnstowers.co.nz/files/win32/pycairo-1.8.6.win32-py2.6.exe I also built 1.8.8 with some hacking of tp_base I am not sure about. The reasons for this hacking is some bug-ish thing in GCC-3.4.5 on cygwin/mingw. This bug is kind of described here http://www.mail-archive.com/patches@python.org/msg02861.html and appears in pycairo here https://bugs.freedesktop.org/show_bug.cgi?id=25203 Both 1.8.6 and 1.8.8 pass all the tests and display the examples correctly, however I am only releasing 1.8.6 at this time. I will add a comment on the upstream pycairo bug. Some additional notes: * Building 1.8.8 required manually copying src/__init__.py to site-packages/cairo/ because it is no longer automatically installed with the extension module. I also could not work out the correct dist-utils argument to install src/__init__.py to site-packages/cairo/__init__.py. I recommend just moving the sourcedir back to cairo so that __init__.py comes along automatically. * The pkgconfig hack I mentioned is to change the prefix from c:\python26 to C:/Python26 so that the mingw path separator substitution magic works on it. I did this using a postinstall script, just like what is done in pygtk/pygobject although this replacement could also be done when the pkg-config file is generated. * The tp_base change was to replace &PyBaseObject_Type with 0 because AFAICT the behaviour is the same for types which directly inherit from PyBaseObject_Type. Other cairo types which inherit from PyCairoSomeOther_Type are not changed, nor do they need to be
Hi, PyPy recently started supporting CPython extensions, and due to our approach we hit the exact same problem (also on Linux). I heard that it's a known problem for Python extensions on Windows (and on PyPy apparently). The attached patch fixes this bug and makes pycairo work on Windows and PyPy. tp_base can be safely initialized to NULL, PyType_Ready initializes it to &PyBaseObject_Type in this case. The patch also adds a missing PyType_Ready call. Thanks in advance. 1. http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html
Created attachment 35345 [details] [review] Fix
1.8.8 doesn't compile on Cygwin either for the same reason. 3925911c9975e148999df9dd0b8106e315e38f15 is definitely the culprit and should be reverted. As for the Python sources, where do you see that this is done there?
To #9 Jan de M. Fixes applied to git repo, thanks.
Thank you. What is the timeframe for 1.8.10?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.