GNOME Bugzilla – Bug 462433
paths to pixbuffer loader dlls are hardcoded
Last modified: 2008-01-15 14:13:13 UTC
Please describe the problem: GIMP requires the next hardcoded path to libpixbufloader-jpeg.dll and libpixbufloader-png.dll as c:/devel/target/98ed7cdc268d9d51095d966121ae118b/lib/gtk-2.0/2.10.0/loaders GTK+ 2.10.13 is already installed stand-alone, but GIMP doesn't see the libraries. Even adding their actual path to PATH system environment doesn't solve the problem. Steps to reproduce: 1. Install fresh 2.3.18 (not over 3.3.14 or earlier). 2. Run the program 3. Read console message and see image preview not working in the file open dialog. Actual results: Expected results: Does this happen every time? Other information:
I can't reproduce this. To be honest, I'm not sure what I should try to reproduce, because the summary implies that the current state is wrong, yet the description indicates that it should be made that way.
Isn't this bug #461703?
So, it is the problem with 2.3.18 under Windows. It didn't displayed when 2.3.18 had been installed over previous development builds, but when I cleared Gimp-2.0 directory after broken 2.3.19 and installed 2.3.18, it appeared. Maybe the problem is caused by 2.3.19 and its changes in the registry, I haven't investigated this. Briefly: when I launched 2.3.18, the console window complained some libraries are missed and pointed to c:/devel/target/98ed7cdc268d9d51095d966121ae118b/lib/gtk-2.0/2.10.0/libpixbufloader-jpeg.dll When I opened any file, the preview didn't work. The only way I found to solve the problem, was to create the required directory and copy dlls from the appropriate GTK directory there. I do not think it is the bug 461703. When I made a workaround thumbnails started saving and opening.
Hm... IMO we should close this bug as INVALID. Maybe open a new one if this problem persists, but comment #3 doesn't make me think it will.
Paths that start with prefixes like c:/devel/target/98ed7cdc268d9d51095d966121ae118b/ in gdk-pixbuf.loaders and gtk.immodules are as expected and work fine in a correctly installed GTK+ for Windows. There is no need to have actual existing paths in the file. Those paths in gdk-pixbuf.loaders and gtk.immodules that start with the compile-time prefix are at run-time edited (in memory, not in the file) to point to the run-time installation prefix instead. The Summary of this bug has it totally backwards. One main feature in GTK+ (and GLib, Pango, etc) on Windows is that no hardcoded paths are used at run-time. One can install GTK+ in any location (even in paths that contain any random Unicode characters not in the system codepage) and it should still work, without having to edit the gdk-pixbuf.loaders or gtk.immodules files to contain actual existing pathnames. This is quite different from how it works on Unix, where there are hardcoded paths in the binaries and those get used as such. The problem the bug reporter is seeing must have some other root cause.
Tor, I haven't imagined it ;). I do have GTK + 2.10.13 installed which is seen by other applications like stardict. GIMP 2.3.18 installed its own F:\Graphics\2D\GIMP-2.0\lib\gtk-2.0\2.10.0\loaders. But when I run gimp-2.3.exe, the console window displays the error message. When I created the directory c:/devel/target/98ed7cdc268d9d51095d966121ae118b/lib/gtk-2.0/2.10.0/ and put there libraries from GTK installation, GIMP stopped complaining and started to show image thumbnails in file opening dialog. I should say the problem appeared after installation of 2.3.19. As it didn't work I tried to make a clean case. So I deleted GIMP directory and ran the installation of 2.3.19 again. It didn't helped. So I installed 2.3.18 over 2.3.19 and was surprised with missing dlls.
I guess the scenario must be something like you have replaced the libgdk_pixbuf-2.0-0.dll file in the GTK+ installation you are using with one from another build of GTK+. (Or the other way, your gdk-pixbuf.loaders is from another build than your DLL.) In that case the prefix in the gdk-pixbuf.loaders file does not match the one in the DLL and will not be replaced at run-time with the correct one deduced from the DLL's location at run-time. Could you open the libgdk_pixbuf-2.0-0.dll file in a binary editor (Emacs works fine) and look for the string /devel/target and check what hex string follows? Paste that prefix here, and also the prefix that actually is in the gdk-pixbuf.loaders file. I use hex strings like that (it's actually the md5sum of strings like "gtk+-2.10.14") in the build-time prefix hoping to make it obvious to people that it's just gobbledygook and such folders are not expected to exist on the end-user system. Maybe I should add a "should-not-exist" or "dont-create-this-folder" as part of the pathname to make it even clearer... I could use something "human readable" like c:/devel/target/gtk+-2.10.14" instead (and I used to earlier), but then the risk is greater (I think) that people think such a folder should exist on the end-user system.
I installed corrected (second build) gimp-2.3.19-i586-setup-1.exe . When I uninstalled it and installed 2.3.18 again, the problem disappeared. I tried to reproduce it again and installed initial 2.3.19 over 2.3.19-1. Then I uninstalled 2.3.19 and installed 2.3.18 again. It worked well without problems! So I guess it was some strange rare case which should be ignored.