GNOME Bugzilla – Bug 139987
gdk-pixbuf-csource not choosing lib64 version of libpixbufloader-png.so
Last modified: 2004-12-22 21:47:04 UTC
Description of problem:
when compiling programs that call
"gdk-pixbuf-csource --raw --build-list xfcalendar_icon xyz.png"
gdk-pixbuf-csource is not smart enough to use
So now the 64 bit app requires the /usr/lib/ .so :-(
I'm using gtk2-2.2.4-4.0 from RHEL3 AMD64
/usr/lib/gtk-2.0 doesn't even exist on RHEL3 AMD64. It's likely you did
something silly and installed part of a 32-bit gtk2 package on your system and
screwed things up.
It most certianly DOES. There are several i386 packages installed in RHEL3
AMD64... gtk2 is one of them:
[jjensen@nbs-lnx-2 jjensen]$ rpm -q gtk2
[jjensen@nbs-lnx-2 jjensen]$ rpm -ql gtk2.i386 | grep lib | head
The i386 package isn't installed on any of my amd64 systems. I wonder what pulls
Regardless, the gtk2 x86_64 and i386 rpms do not coexist peacefully together.
You should file a bug with red hat about this, it's a system misconfiguration
problem, and not a problem with the actual gtk sources.
As a workaround, you can simply reinstall the x86_64 gtk2 package. What happened
here is that /etc/gtk-2.0/gdk-pixbuf.loaders points to the 32-bit libraries.
This is generated from gdk-pixbuf-query-loaders.
No, it's a GTK+ problem. We have a horrible hack in the Pango RPM to make
the 32bit and 64bit packages coexist for Pango, but the same thing
hasn't been done for gdk-pixbuf.
(And a duplicate bug)
*** This bug has been marked as a duplicate of 129540 ***