Re: [PyOpenGL-Users] Loading PyOpenGL from embedded Python interpreter

[Thomas W. <th...@xs...>]

On Fri, Apr 25, 2003 at 06:59:39AM -0500, Patrick Hartling wrote:

> My group is having some problems trying to load a Python module that
> uses PyOpenGL (2.0.0.44) from C++ code that includes an embedded Python
> interpreter.  This is happening on Red Hat Linux 8 and FreeBSD 5.

> The first issue we ran into was unresolved Python/C symbols in various
> .so files in the PyOpenGL installation.  I attempted to fix this by
> changing the PyOpenGL build so that all the .so's are linked with
> -lpython2.2 and -lutil.  This appears to address the unresovled symbol
> problem, but now I have a new problem that I can't seem to figure out.

I think this 'solution' actually caused your new problem. Instead, you need
to build your application in a dlopen()-friendly way: tell your linker to
export all symbols in your application to the dynamic symbol table. This is
not the default behaviour, but practically always necessary for applications
that want to dlopen().

I haven't used Boost myself, nor built C++ applications, nor embedded Python
using distutils or other more 'modern' built systems, but way back when
(cough) you were supposed to use the Makefile.pre that came with the Python
against which you were building. Makefile.pre is a template makefile that
contains the right variables to embed Python into your program -- which
libraries to link to, for instance, which compiler to use, et cetera. It
still gets built, and indeed, on my Linux system, it contains (among other
things):

CCSHARED=       -fPIC
LINKFORSHARED=  -Xlinker -export-dynamic
LIBS=           -lrt -ldl  -lpthread -lutil

I can't imagine e.g. distutils and whatever-Boost-does not providing this,
as it's quite crucial information for embedding, and it can vary per
platform (for instance, -lutil is not always necessary or available.)

> When I run the C++ application that loads the Python module, I get this
> error:

> Fatal Python error: Interpreter not initialized (version mismatch?)

Because you only have libpython2.2.a, using -lpython2.2 means that Python
2.2.2 is linked statically into the PyOpenGL .so's (and each seperately, at
that.) You should not link those .so's with -lpython2.2, and preferably not
with -lutil either (but that one probably is shared, so might turn out
okay.) If you really don't want to do the above, you can built
libpython2.2.so using one of the patches out there (many Python
distributions do that) or you can wait for Python 2.3, which can build
libpython2.3.so for more platforms (using --enable-shared).

-- 
Thomas Wouters <th...@xs...>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!