I have encountered a lot of cases in which there are shared library errors in 32-bit programs running on FC2, most commonly for gtk2 libraries. For example, running the realplayer 10 from www.helixplayer.org, I have the following errors: Failed to load pixbuf file: /usr/local/RealPlayer/share/realplay/icon.xpm: Unable to load image-loading module: /usr/lib64/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: /usr/lib64/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: cannot open shared object file: No such file or directory (realplay.bin:14318): GdkPixbuf-CRITICAL **: file gdk-pixbuf-io.c: line 762 (gdk_pixbuf_new_from_file): assertion `error == NULL || *error == NULL' failed (realplay.bin:14318): GdkPixbuf-CRITICAL **: file gdk-pixbuf-io.c: line 762 (gdk_pixbuf_new_from_file): assertion `error == NULL || *error == NULL' failed ... It is looking in the wrong place (/usr/lib64 instead of /usr/lib) for the 32-bit libraries. I can fix the problem if I do a global change of lib64 to lib and x86_64 to i386 in the files in /etc/gtk-2.0, but this breaks the 64-bit programs. Putting both sets of links in the file also fails (unless I am guessing wrong about what syntax I need) because only one link is checked before failure. This issue was raised before in a post by Aleksander Demko but nobody here has suggested a solution. Eventually, I hope that gtk2 will be changed to work correctly on biarch systems (presumably by having a separate configuration file for each architecture, or perhaps by making it able to try separate configurations in one file). In the meantime, there is an extreme workaround suggested at http://www.linuxtx.org/amd64faq.html (which is a great resource but a little terse for me). By installing the 32-bit operating system alongside the 64-bit system and then mounting it within the file system, chroot (change root) and setarch (tell programs the architecture is 32-bit) may make it possible to run 32-bit programs with the right library even if /etc/gtk-2.0/* points to the 64-bit versions. For example, if the root / of the 32-bit installation is mounted at /i386 in the 64-bit installation, chroot /i386 and setarch i386 make the 32-bit program we are running think it is on a 32-bit machine and it will look at the 32-bit libraries pointed to by /i386/etc/gtk-2.0/* (which is /etc/gtk-2.0/* in the 32-bit installation). I haven't tried this yet, but I am downloading a 32-bit ISO image to give it a try. Even if it works, installing a second operating system is an extreme solution to the problem of not finding shared library files that after-all are already installed. On a bright point, the frequent bluecurve.so errors I have seen can be eliminated by changing the default theme name in /etc/gtk-2.0/gtkrc to "Raleigh". I should also mention that most things are working on my x86_64 box. -- Phil PS If I am wrong about all this and someone can offer a simple fix to the gtk libraries problem, I would be delighted. :-)
