Hmmm, I've run across this also. It turned out that I needed to create a shared library. If the original file is foo.c, compile it to foo.o then create a shared object called foo.so with ld -shared foo.o -o foo.so. Then it won't mind the undefined symbol (which gets loaded at run time)
Mathew > I have a feeling that I'm still doing something wrong, because calling > the macros from pygtk.h was harder than it ought to be. I'm > including pygtk.h like this: > > #define NO_IMPORT_PYGTK > #include <pygtk.h> > #undef NO_IMPORT_PYGTK > > That works as long as I don't use any macros. If I call > PyGtk_BlockThreads, then python complains that _PyGtk_API is > undefined and won't load my module's .so file. So I declared my own > copy of _PyGtk_API, which feels like the wrong thing to do, but seems > to work. Then I initialize it by duplicating the init_pygtk macro. > (The reason that I can't just call init_pygtk directly is that it > won't compile with g++. g++ says that the line > _PyGtk_API = PyCObject_AsVoidPtr(cobject); > requires an explicit cast.) > > Thanks again. > > -- Steve > > > -- > /* EMail: [EMAIL PROTECTED] ------------------ Phone: (301) 975-5423 -- > -- WWW: http://math.nist.gov/~SLanger/ ------------ Fax: (301) 990-4127 -- > -- Mail: NIST; 100 Bureau Drive -- Stop 8910; Gaithersburg, MD 20899-8910 */ _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
