Presumably the reason for not using the RTLD_GLOBAL flag is so you can
load modules that contain symbols (ie. global variables and non static
functions) with the same name without any namespace problems. This is
a good idea, but breaks an assumption in the shared module loading code
for imlib's image loaders and gtk theme engines -- that is that the
gdk_imlib, gdk or gtk libraries will be in the program'symbol table.
The simple fix for this is to have the image loaders/theme engines
dynamically link against the required libraries. According to my system,
the png image loader only links against libpng, libz and libc. To fix
this, you would edit imlib/gdk_imlib/Makefile.am, and change lines like:
libimlib_xxx_la_LIBADD = ...
to:
libimlib_xxx_la_LIBADD = ... libgdk_imlib.la
After recompiling imlib with this change (you may have to delete the
gdk_imlib/libimlib-*.la files to get it to relink them), the imlib
slowness problems should disapear. Similar fixes can be made to the gtk
theme engines. For these, we would add $(GTK_LIBS) to the end of the
_LIBADD line. To the person who noted that thin ice did not have this
problem -- maybe its theme engine is already linked against libgtk. This
can be checked by running ldd on the shared library.
Under linux, these changes will not break anything. I don't know about
other platforms though. If you know of anything that this sort of change
would break, please tell me. If it seems that it wont break anything, I
will ask round on gnome-hackers, and maybe apply these patches to
gtk-engines and imlib.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On Thu, 13 May 1999, Bill Allen wrote:
> I tried this and it worked exactly as James has conjectured. The slowness
> associated
> with running pygnome programs when using pixmap themes has disappeared.
>
> I suppose the question is, why did (presumably Guido) decide that loading
> with the RTLD_GLOBAL flag was a bad idea?
>
> Bill
>
> James Henstridge wrote:
>
> > I was just wondering about this problem. I personally use python 1.5.1 (I
> > haven't had time to upgrade yet), and many of the people who have been
> > reporting problems seem to be using python 1.5.2.
> >
> > I checked the file at http://www.python.org/1.5/NEWS-152.txt, and it says
> > the following for the summary of changes between 1.5.1 and 1.5.2a1:
> >
> > - Revert a new feature in Unix dynamic loading: for one or two
> > revisions, modules were loaded using the RTLD_GLOBAL flag. It turned
> > out to be a bad idea.
> >
> > If I am correct, this means that in 1.5.2, the symbols in the _gtk module
> > (including those from libgtk.so and libgdk.so, which are dynamically
> > linked to _gtkmodule.so) are not available to the main program. So when
> > gdk_imlib trys to load its png reader or whatever, the png reader can't
> > see the imlib symbols, so fails with a dynamic linker error. It would be
> > a similar problem for theme stuff.
> >
> > If someone who was having trouble with the dynamic loading, and still have
> > the source tree on there system, and don't mind recompiling python, would
> > you mind trying something for me? You would have to edit the source file
> > that is responsible for dynamic module loading (it would be in the Python
> > sub directory, and would be the only one containing a call to dlopen). In
> > that file, find all calls to dlopen, and add the flag RTLD_GLOBAL to the
> > second parameter. That is, if the call looks like this:
> > dlopen(string_variable, RTLD_NOW)
> > to:
> > dlopen(string_variable, RTLD_NOW|RTLD_GLOBAL)
> >
> > Now do a recompile, and see if this fixes the problems with pixmap themes
> > and pygtk.
> >
> > If this is not the cause of the problem, I don't know what is.
> >
> > James.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
