Hi *,
sorry for bothering you all on this problem that is only slightly
debian-related (involves two of my packages) but I really need some help
here.
I am the current maintainer for ogre (libogre5 & other packages) and the
upstream for the PyOgre bindings (that I am also packaging). After the
big switch to gcc 4 PyOgre programs started to segfault and I had to
link ogre plugins into the PyOgre Python module (_ogre.so) _explicitly_
to make the segfault disappear.
Let me explain a little better: ogre provides various rendering backend
and on Debian we use the OpenGL one, located in shared object in
/usr/lib/OGRE/RenderSystem_GL.so
The render system is loaded at runtime (dlopen()) by the main ogre
library (libOgreMain.so.5) and for normal C++ program all goes well. The
Python module is usually linked with libOgreMain.so.5 only (as the C
programs are) to produce a shared object that is dlopen()ed by Python
(_ogre.so).
Now, the extact segfault location depends on the Python script and on
the exact versions of the ogre libraries (and compile options and so on)
but it always happens inside the render system shared module (i.e.,
inside RenderSystem_GL.so). If _ogre.so is explicitly liked against
RenderSystem_GL.so the segfault disappears.
I double checked all the involved libraries and it seems that they are
all linked with libstdc++.so.6 so it does not seem to be a library
conflict (gcc 3.3 vs gcc 4.0).
My wildest guess is that a dlopen() from a dlopen()ed shared object can
do something bad but I can't find any reference to similar problems.
Ideas?
federico
--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer fog@debian.org
INIT.D Developer fog@initd.org
I came like Water, and like Wind I go. -- Omar Khayam
Attachment:
signature.asc
Description: This is a digitally signed message part