[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

x86_64: biarch shared libraries broken for gtk2 on FC2?



  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.  :-)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]