Steve M. Robbins wrote:
Hmm. The Makefile.am looks a bit weird in the gdk_imlib directory.You should just list the .la file on the _LIBADD line for each of the loader modules, rather than .libs/libgdk_imlib.so.Thanks. That appears to fix it!
For the record, the reason you are seeing the problem with the python bindings and not the C bindings is the way the library is loaded.
In the C program, imlib is directly linked to the app, and all its symbols are available in the global symbol table. The loader modules require those symbols in order to do their job, so they should be linked against libgdk_imlib. If they are linked incorrectly, it is no big deal because the symbols will be in the global symbol table so things resolve okay.
For python, we have an extension module which is linked against imlib. That extension is dlopen'd by the python executable _without_ the RTLD_GLOBAL flag, so none of the symbols in the extension module or imlib are added to the global symbol table (they are only available through dlsym() calls). Now when imlib tries to dlopen() an image loader module, it can't find the symbols it needs, so dlopen() returns an error. Correctly linked loaders will not have this problem.
Note also that it wasn't until libtool-1.4 that libtool could actually handle linking one shared lib to another uninstalled lib (needed in this case, as both imlib and the loaders are built and installed together).
This isn't a python specific problem -- it will happen in any case where gdk_imlib, etc are dlopen()'d without RTLD_GLOBAL. There were similar errors w.r.t. themes and mozilla, for instance, which have been fixed.
Mark: any chance of a quick bugfix release of imlib? (no point in it only getting fixed only in Debian).
James. -- Email: james@daa.com.au WWW: http://www.daa.com.au/~james/ -- To UNSUBSCRIBE, email to debian-gtk-gnome-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org