gdk-pixbuf2 loaders.cache missing, loads themes incorrectly

[snarkhunter (Steve Langer)]

After upgrading to gdk-pixbuf2 @2.31.2_0+x11, when running a program using pygtk (py27-pygtk @2.24.0_3+x11) I see the message:

GtkWarning: Cannot open pixbuf loader module file '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.

It also fails to load and render the theme properly. If I revert to the default theme, it appears to render properly, although the message about loaders.cache is still there.

Reverting to gdk-pixbuf2 @2.31.1_1+x11 makes the problem go away.

[dbevans (David B. Evans)]

Which program are you running?

[su-v]

Cc Me!

[su-v]

This is caused by an upstream change in 2.31.2 (​io: extend support for relotations to OS X and Linux) which unconditionally enables relocation support (a 'bundle' mode) for gdk-pixbuf2 on darwin (see also MacPorts' gtk2 variant bundle; with GTK+ this is a configure option, even on OS X).

Ideally, such relocation support would be made configurable (by patching configure.ac), and turned into an (optional) variant (bundle) in MacPorts, like already in use with the gtk2 port.

The upstream change also breaks any local builds from source which are configured with a custom prefix outside of the MacPorts tree and use shared libraries (including gdk-pixbuf2) installed via MacPorts. OTOH it works ok if used with bundled (self-contained, fully relocatable) applications.

[snarkhunter (Steve Langer)]

I'm using pygtk as part of a large program that we develop for OS X and Linux. It's a python program (with a lot of C++ extensions) and is distributed as source code. The build scripts copy python scripts and compiled libraries into the site-packages and lib directories that the user specifies. We don't do any bundling...

[dbevans (David B. Evans)]

Replying to stephen.langer@…:

I'm using pygtk as part of a large program that we develop for OS X and Linux. It's a python program (with a lot of C++ extensions) and is distributed as source code. The build scripts copy python scripts and compiled libraries into the site-packages and lib directories that the user specifies. We don't do any bundling...

Nevermind, I'm able to reproduce the problem using port deluge. As stated in comment:4, the relocation support is causing a path relative to the python installation directory to be used

/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/../lib/gdk-pixbuf-2.0/2.10.0/

rather than the gdk-pixbuf2 installation path

[dbevans (David B. Evans)]

Fixed as suggested in r132232, application bundle relocation is disabled by default, +bundle variant added to enable if desired. Tested successfully with deluge.

Thanks to all for the report and the solution.

[snarkhunter (Steve Langer)]

That fixes the problem I was seeing.

Thanks for the quick response.

[craftey]

I had the same problem with port meld in +quartz mode for gtk stuff. This update fixed it for me. Thx for the quick fix. Finally I am able to build meld with quartz :)