Philipp Schumann

Disrupt, constructively. Construct, disruptively. 
« Back to blog

Cannot import PyCairo in Python 3.0 (ImportError: dlopen / "Expected in: flat namespace")

Dear Lazyweb,

 I'm in the process of moving my code base to Python 3.0. On Mac OS X 10.5.6, I've upgraded both Cairo and PyCairo to 1.8.0; then in /Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/site-packages/ ran 2to3 -w cairo and removed the __init__.pyc file.

 After restarting Eclipse Ganimede /w Pydev and trying to run my code, I got the following ImportError:

  File "/Users/roxor/dev-py/metaleap/src/metaleap/core/gfx.py", line 2, in
  import cairo
 File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/site-packages/cairo/__init__.py", line 1, in
  from ._cairo import *
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/site-packages/cairo/_cairo.so, 2): Symbol not found: __Py_ZeroStruct
 Referenced from: /Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/site-packages/cairo/_cairo.so
 Expected in: flat namespace

 Any ideas how this can be fixed "quick-and-dirty"-ish? I'm far from a production release anyway so I don't have to wait until pycairo "officially" supports Python 3000. Just any ideas to quickly and easily get Python 3.0 / pycairo to work with the current _cairo.so dynamic library would be *highly* appreciated...

Loading mentions Retweet

Comments (2)

Jan 05, 2009
Gerdus van Zyl replied on the Cairo mailing list, here's his reply (embedded) and (outside) mine:

Hi, thanks for getting back!

Sounds reasonable, except all "Pycairo" is *actually* "doing" is importing a dynamic library (.so) written in and compiled from C. I can't imagine the semantics of that having changed to drastically in 3.0, so I was wondering whether anyone here has some experience with 3.0 as well and could give me a hint. Maybe I'll ask in some 3.0 mailing lists or forums, too.

As you said, "it's a fairly straightforward binding". So I can't comprehend how this C library possibly *could* (technically) be "recompiled against" py3k. "Pycairo" itself is "just" the __init__ one-liner, no? 2to3 changed that for me so I don't think that's the problem.

> At the very least you will need to compile pycairo/cairo yourself and
> pycairo against py3k. It's a fairly straightforward binding so errors
> should be fixable. That being said it won't be trivial. Any reason why
> you are moving to Python 3.0 so fast? Since it's a breaking release
> expect a few years before everything ported.

Yeah, basically my code base is still in its early stages but will be project of a few years to come. I've only got 1 or 2 months worth of code at that point, I'm far from release to production but I know I will eventually have to upgrade to py3k, so I'd rather have it there *now*, even if rough around the edges. Most of the other libs I use were either already "ported" or I could do it myself painlessly with 2to3, no headaches or troubleshooting involved, thankfully. That includes mako, Werkzeug, couchdb, simplejson, httplib2. So for me the upgrade isn't that "breaking". Except for Cairo, but heck, at the end of the day it's "just" C bindings, so I'm thinking it should be possible to somehow "rebind" that, no?

Any of the Cairo core hackers fancy giving it a spin? Maybe it's an easy hack, otherwise don't bother and I'll revert to 2.6 for now... Shamefully, I've never done any C or else I'd already be getting my teeth into that at that point now.

Leave a comment...

 
Got an account with one of these? Login here, or just enter your comment below.
Posterous-login    Connect    twitter