x86_64 pixbuf hack for 32-bit/64-bit shared libraries
fedora at ducksoup.afree.net
Sat Jul 17 02:04:58 UTC 2004
I gave a rant here earlier about the problems of parallel 32- and 64-bit
shared libraries in x86_64. Here is an ugly hack that seems to eliminate the
libpixbuf errors (but no guarantees from me that it will not break your
system!). The problem is that gtk2-2.4.0-1.i386 and gtk2-2.4.0-1.x86_64 are not
designed so they can both be installed at once. We need the x86_64 version to
run 64-bit programs (including a lot of our interface), and the 32-bit version
to run 32-bit programs. For, example, the new realplayer 10 for linux at
www.helix.org is only available in a 32-bit version, and a 64-bit version will
probably not be available anytime soon because the proprietary codecs are
32-bit binaries. However, running realplayer gives error messages like:
Failed to load pixbuf file:
Unable to load image-loading module:
/usr/lib64/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: cannot open
shared object file: No such file or directory
because the program does not know how to find the 32-bit gtk2 shared libraries.
Here is what I did. (In case someone is here by accident, this is only for an
x86_64 install of FC2. If you don't know what this means, stop here!)
1. Get gtk2-2.4.0-1.i386.rpm and gtk2-2.4.0-1.x86_64.rpm from fedora.redhat.com
or better yet a mirror (http://fedora.redhat.com/download/mirrors.html). The
rpms will be in a directory .../fedora/linux/core/2/arch/os/Fedora/RPMS where
arch is i386 or x86_64.
2. Force install the two rpm's starting with the i386 rpm:
rpm -i --force gtk2-2.4.0-1.i386.rpm
rpm -i --force gtk2-2.4.0-1.x86_64.rpm
We need --force because the two packages share some files. We install the
x86_64 package second so that we at least have all the correct 64-bit files
expected by our windowing system etc.
3. Edit the files in /etc/gtk-2.0/ to include both 64-bit '/lib64' and 32-bit
'/lib' versions. Replace "Bluetooth" by "Raleigh" in gtkrc. My patched files
are in the directory URL http://yellow.brick.net/gtk and may work for you if our
installations are similar enough.
Try using realplay10 or whatever and it should work better.
I am not proud of this fix (since I don't understand exactly what other
problems there might be with remaining duplicated files) and I cannot really
recommend it. It does seem to work for me. Hopefully, a better construction
of the RPMs (maybe a smarter version of the postinstall script Bryan O'Sullivan
mentioned) and/or a better structure for gtk files will make all of this
unnecessary in the future.
More information about the users