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

[Patrick H. <pa...@vr...>]

Thomas,
	Your suggestions all seem right on target, but for some reason, they 
don't work for me.  I've verified that all the options I know about are 
being used, including the ones you mention.  I'm testing with my original 
build of PyOpenGL that doesn't have any of the modifications I described 
in the original message.  I guess I'll keep scanning the ld(1) manpage in 
case there's something I am missing.
	Regarding Python 2.3, unfortunately, I have a deadline in two weeks, so 
I can't wait for it--though I may try an alpha or a beta version if I get 
totally frustrated.

  -Patrick

Thomas Wouters wrote:
> 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).
> 



-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@vr...                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/