Stephen Langer wrote: >On Tue, May 14, 2002 at 07:22:52PM -0700, Mathew Yeates wrote: > > >>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 >> >> > >We are creating a shared library, with -shared. Python still won't >load a shared library with an undefined symbol in it. Are we doing >something dumb? The C++ code contains > >#define NO_IMPORT_PYGTK >#include <pygtk.h> >#undef NO_IMPORT_PYGTK > >and (later, within a canvas item callback) > > PyGtk_BlockThreads(); > PyObject *result = PyEval_CallObject(pycallback, args); > PyGtk_UnblockThreads(); > >When compiled into a shared library, python says > >ImportError: /u/home3/langer/FE/OOF2/INTEL/oofcppcmodule.so: undefined > symbol: _PyGtk_API > >If I add my own pointer to _PyGtk_API and call the (slightly modified) >init_pygtk macro, then it all works. As I said, this feels wrong to >me. It looks like there's no harm in calling init_pygtk an extra >time, but I'd rather not have to copy names like _PyGtk_API out of the >nominally private parts of the header file... > > In one of the source files for your module you must not define NO_IMPORT_PYGTK (all others, you should define it). You would then need to copy the contents of the init_pygtk() macro to your code and fix the C++ cast problem.
The idea is that in the main file, you include pygtk.h, and call init_pygtk(). In the other files, you define NO_IMPORT_PYGTK before including pygtk.h. James. -- Email: [EMAIL PROTECTED] | Linux.conf.au 2003 Call for Papers out WWW: http://www.daa.com.au/~james/ | http://conf.linux.org.au/cfp.html _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
