"Couldn't recognise the image file format for file ...xpm"

[hazel]

I have two systems - Crux and a variant of Slackware - which share a common documents partition mounted on /home/data. Within this, I have a program that runs normally in Crux but refuses to load images when built in Slack. There are no warnings during the build, and ldd shows that all required libraries have been found and loaded. The versions of gtk2, libpng, libXpm and gdk-pixbuf are the same in both systems.

gtk_image_new_from file() simply shows broken images. When I use gdk_pixbuf_new_from_file() and gtk_image_from_pixbuf(), I can extract a GError message "Couldn't recognise the image file format for file .....xpm". But it's not specific to xpm. Exactly the same thing happens when I replace some of the xpm's with png files. And the window icon (which is also a png) generates the same error.

This kind of thing usually has a ridiculously simple cause, but so far I can't find it.

[hazel]

This gets curiouser and curiouser. When I mount the Slackbody partition in Crux and run the program built under Slackbody, it works normally. So the build is OK, it's the runtime environment that causes the problem.

So I set LD_PRELOAD to the Slackbody /usr/lib (export LD_PRELOAD=/mnt/slackbody/usr/lib), which should cause the program to run with the Slackbody libraries rather than the Crux ones. And again, it loaded the images correctly. So there's nothing wrong with the libraries. I had already guessed that because other gtk programs such as gvim run normally.

What else could I possibly have in Crux that makes the difference?

Of course I then tried the same experiment in reverse and got the answer I expected. The program compiled in Crux does not load images in Slackbody, even when I use LD_PRELOAD to make it prefer the Crux libraries.

Can anyone explain this?

[hazel]

At last I'm getting somewhere! I was using LD_PRELOAD wrong. You have to point it at the actual system object, not the library directory. When I did that, I got the following very interesting result:

1) Running in Crux, the program worked regardless of whether I was using the Crux or the Slackbody version of gdk-pixbuf.

2) Running in Slackbody, the program worked with the Crux version of gdk-pixbuf but not with the native Slackbody one.

The two libraries are not quite the same. Crux uses version 2.22 and Slackware-13.37/Slackbody use 2.23. The Crux version is linked against libpcre and the Slack version isn't. Could there be a subtle bug in the library? It doesn't seem to affect standard gtk programs, but they may include code that makes them more robust; I'm just an amateur after all.

[Rubberman]

Well Hazel, if you were living in the US, I think I'd have our staff recruiter make you an offer you couldn't refuse (we currently have 25-30 openings for software engineers in the Chicago area)! Nice diagnostic work, in any case. From what you are describing, I don't think this is a bug in gdk-pixbuf, but rather in something it is linking to or dependent upon. You said that both versions of this library work on Crux, but on Slackbody, only the Crux version works. That would seem to reinforce this opinion. If you can get the debug versions and sources of these libraries, perhaps you can see what is going on in the debugger?

[hazel]

Your theory makes a lot of sense. I think the next step is to look at all the libraries that gdk-pixmap links to and compare their versions. Only one that is different in Crux and Slackbody is likely to be causing this. But I should still like to know why the problem affects only my own program and not programs like geany and gvim.

I don't know anything about gdb; I've never used it. If we do any serious debugging, I shall need someone to hold my hand.

PS: I've done the library check. There are two groups of libraries that differ in version. The first group are parts of glib: libgio, libgobject, libgmodule, libgthread and libglib itself. The other group are libc and its parts: libdl, libpthread, libm and so forth. In addition, the Crux version of gdk-pixbuf links to libpcre and the Slack version doesn't.

My instinct is that its more likely to be glib (or the absence of libpcre) than libc. libc is just too basic to go wrong.

[hazel]

It's the pixbuf loader! I tested all the dependent libraries by relinking to the Crux versions and none of them made any difference. But when I renamed libpixbufloader-xpm.la and libpixbufloader-xpm.so, and copied over the Crux versions to use instead, everything worked. Strangely png icons now load correctly too, although I didn't change the loader for them.

Where do we go from here?

[Rubberman]

You are awesome Hazel! Now, you get to report it to the gdk maintainers, wherever they are roosting... Anyway, I think you deserve the debugger-of-the-month award here, if they had one!

[hazel]

You are awesome Hazel! Now, you get to report it to the gdk maintainers, wherever they are roosting... Anyway, I think you deserve the debugger-of-the-month award here, if they had one!

Well, you can take back your bananas. The rejoicing was premature. I was tired last night and I made an elementary mistake; I forgot to unset LD_PRELOAD before testing the new "solution". That's why it worked. I have just tried again with the Crux xpm loader still in place but without LD_PRELOAD set and it doesn't load anything.

I can work round it, of course, by writing a little script to mount Crux, set LD_PRELOAD, run the program, then unset LD_PRELOAD and unmount Crux before exiting. But that's a bodge and I hate bodges. I'd rather have an explanation.

I have tested all the dependencies of gdk-pixbuf to see if using the Crux versions of them within Slackbody works better. Nothing doing! I'm at a loss to know what to try next. The key to it has to lie in the fact that proper gtk apps run OK in Slackbody; it's only my program that doesn't. So something must be wrong with my code.