Bug 25203 - Unable to compile on windows, mingw32
Summary: Unable to compile on windows, mingw32
Alias: None
Product: pycairo
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Windows (All)
: high critical
Assignee: Steve Chaplin
QA Contact:
Depends on:
Reported: 2009-11-20 10:46 UTC by Paul
Modified: 2010-05-19 19:20 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Fix (4.80 KB, patch)
2010-04-30 07:09 UTC, Jan de M.
Details | Splinter Review

Description Paul 2009-11-20 10:46:21 UTC
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
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
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   )

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)
    171     return dist

SystemExit: error: command 'gcc' failed with exit status 1
Comment 1 Steve Chaplin 2009-11-23 16:40:54 UTC
What pycairo and mingw32 versions are you using?
Comment 2 Paul 2009-11-24 06:20:16 UTC
(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.
Comment 3 Steve Chaplin 2009-11-30 04:13:41 UTC
What is the gcc version ?
Comment 4 paul 2010-01-10 05:54:38 UTC
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')
Comment 5 paul 2010-01-10 07:25:01 UTC
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 */
Comment 6 Steve Chaplin 2010-01-11 02:59:20 UTC
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.
Comment 7 John Stowers 2010-01-22 04:54:20 UTC
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


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.


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


and appears in pycairo here


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
Comment 8 Jan de M. 2010-04-30 07:08:04 UTC

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
Comment 9 Jan de M. 2010-04-30 07:09:11 UTC
Created attachment 35345 [details] [review]
Comment 10 Yaakov Selkowitz 2010-05-04 14:25:43 UTC
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?
Comment 11 Steve Chaplin 2010-05-04 16:40:15 UTC
To #9 Jan de M.
Fixes applied to git repo, thanks.
Comment 12 Yaakov Selkowitz 2010-05-04 17:14:02 UTC
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.