Re: Bug#139541: imlib is *BORKED*
Hello Eric,
I'm sorry for the breakage. I've come up with a workaround that I
will upload later today, but I'm a bit puzzled about the problem,
so I thought I'd see if the python-gdk-imlib, libglib1.2 maintainer,
or any of the gtk/gnome crowd knows the score.
Imlib used to have a "fallback" mode whereby an image whose format is
not handled internally would be passed through Imagemagick's "convert"
program to change it to PNM format. This was recently disabled, which
uncovered a strange bug.
The debian packages *should* handle many formats internally, including
GIF, JPEG, PNG, TIFF, PS, BMP, XPM, and PPM. Indeed, I can compile
and run the following C code, and successfully load a PNG image.
#include <stdio.h>
#include "gdk_imlib.h"
int
main( int ac, char* av[] )
{
GdkImlibImage* img;
if (ac != 2) {
fprintf( stderr, "usage: %s filename\n", av[0] );
return 33;
}
img = gdk_imlib_load_image( av[1] );
if ( img == NULL ) {
fprintf( stderr, "failed to load file '%s'.\n", av[1] );
return 1;
}
return 0;
}
Eric sent me a piece of python code which is basically the same.
On Fri, Mar 22, 2002 at 05:11:49PM -0500, Eric Gillespie wrote:
> This small test case demonstrates total breakage of imlib:
>
> import gtk
> import GDK
> import GdkImlib
>
> image = GdkImlib.Image("/usr/share/pixmaps/gnome-info.png")
but which fails to run
> monkey:~# python image.py
> gdk_imlib ERROR: Cannot load image: /usr/share/pixmaps/gnome-info.png
> All fallbacks failed.
> See /usr/share/doc/gdk-imlib1/README.fallback.
> Traceback (most recent call last):
> File "image.py", line 5, in ?
> image = GdkImlib.Image("/usr/share/pixmaps/gnome-info.png")
> File "/usr/lib/python2.1/site-packages/GdkImlib.py", line 33, in __init__
> self._im = _gdkimlib.gdk_imlib_load_image(filename)
> IOError: couldn't load image
I have reproduced the failure here.
Now, here's the weird bit: this python code ultimately calls the same
gdk_imlib_load_image() function of libgdk_imlib.so that the previous C
code calls!
I have inserted printf() statements into libgdk_imlib and verified
that the C and python make the same calls up to this line
m = g_module_open (path, G_MODULE_BIND_LAZY);
(in gdk_imlib/module.c:get_module_loader_saver() from libgdk_imlib
code).
In both cases, path is the correct path to the module
(/usr/lib/gdk-imlib1/libimlib-png.so), which exists and is readable.
However, in the C code, a valid module is returned, while when called
via python, m is NULL.
So, can anyone speculate on what is different when invoked via
python-gdk-imlib ?
In any case, I can work around this problem by compiling all the
image loading & saving code directly into libgdk_imlib rather than
building the modules.
-Steve
P.S. For Eric, here are some more answers to the bug report.
> OK, that looks bad enough. So i open the README and it looks like
> imlib doesn't support PNG or XPM anymore.
Oh! This is not the case, so I'll need to work on the README text.
Imlib should definitely still handle PNG and XPM and the other formats
I mentioned above.
> Great. That file implies
> it does support JPEG so i run convert myself and get a gnome-info.jpg
> to try:
> monkey:~# convert /usr/share/pixmaps/gnome-info.png /usr/share/pixmaps/gnome-info.jpg
> monkey:~# python image.py
> python: relocation error: /usr/lib/gdk-imlib1/libimlib-jpeg.so: undefined symbol: _gdk_malloc_image
Mea culpa for this one. I'm doing away with these plugins for the
next upload, so this should not recur.
-S
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
--
To UNSUBSCRIBE, email to debian-gtk-gnome-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: