32-bit libraries erroneously load 64-bit libraries

Bug #781870 reported by Hadmut Danisch
144
This bug affects 29 people
Affects Status Importance Assigned to Milestone
ia32-libs (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: ia32-libs

Hi,

please see bug #779665 , I meanwhile believe that this could be a bug of the ia32-libs package. It seems as if programs like

/usr/lib32/libgdk_pixbuf-2.0.so.0

erroneously load further libraries such as
/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so

from the 64 bit libs under /usr/lib instead of

/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so where the 32bit version can be found.

Seems to be a wrong path configured.

regards

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: ia32-libs 20090808ubuntu13
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
Architecture: amd64
Date: Thu May 12 21:18:48 2011
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427.1)
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/tcsh
SourcePackage: ia32-libs
UpgradeStatus: Upgraded to natty on 2011-05-04 (8 days ago)

Revision history for this message
Hadmut Danisch (hadmut) wrote :
Revision history for this message
Hadmut Danisch (hadmut) wrote :

Is anybody listening/working on that bug?

Any chance to get that fixed soon?

Revision history for this message
Hadmut Danisch (hadmut) wrote :

OK, after more debugging and reading ubuntu sources I found the precise reason and how to workaround it.

Reason: Ubuntu's method of creating the 32bit versions of these packages for the 64bit ubuntu has a bug (see debian/rules of ia32-libs). It does not recompile the libraries, but simply take the packages from the 32 bit ubuntu, and repackages by extracting them, moving things from /usr/lib to /usr/lib32, and repackaging them.

This in general works. Unfortunately, the gdk-pixbuf library has a hard-coded path under /usr/lib to look for several modules loaded at runtime. This works under 32bit Ubuntu. Obviously, the described method to change 32-bit into 64-bit packages does not and cannot change this path. Therefore, the library under /usr/lib32 still loads the module catalog from /usr/lib and thus the modules from /usr/lib -> bang.

Workaround 1: Fortunately the gdk-pixbuf allows to override the hard coded path to the catalog file with an environment variable. Set

export GDK_PIXBUF_MODULE_FILE=/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache

Workaround 2: Fortunately, the gdk-pixbuf tries to load loaders.cache.32 before loaders.cache. Set a Symlink from

/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache.32 to
/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache

My next problem would be to find a package maintainer feeling somewhat responsible or in charge to fix that bug or at least put the workaround 2 in the package.

Revision history for this message
Mario César Señoranis (mariocesar) wrote :

Thanks Hadmut.

This problem affects Skype 64 version on Ubuntu 11.04, reading your comments I add a launcher with the command

$ GDK_PIXBUF_MODULE_FILE=/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache skype

To fix the crash on loading an image.

Revision history for this message
papukaija (papukaija) wrote :

This bug report is being marked as confirmed because it is affecting more than one person. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status . Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in ia32-libs (Ubuntu):
status: New → Confirmed
Revision history for this message
Andrew (andrew-rw-robinson) wrote :

The work-around does not work 100% for firefox.

Download firefox 3.6.17 32 bit and run with this command-line:

GDK_PIXBUF_MODULE_FILE=/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache ./firefox -P

Here is just a little of the errors printed:

/usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so: wrong ELF class: ELFCLASS64
(firefox-bin:21895): Gtk-WARNING **: Failed to load type module: /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so
/usr/lib/gio/modules/libgiobamf.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgiobamf.so
/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
(firefox-bin:21895): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/immodules/im-ibus.so: wrong ELF class: ELFCLASS64
(firefox-bin:21895): Gtk-WARNING **: Loading IM context type 'ibus' failed

Firefox comes up and it has icons (did not without setting the module file env variable), but I am not sure what is breaking at this point.

I also tried this and it did not help:
(cd /usr/lib/gdk-pixbuf-2.0/2.10.0 && sudo ln -s /usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache loaders.cache.32)

Revision history for this message
Ced-le-pingouin (cedric-floquet) wrote :

I'm affected by this bug.

The work-around did work for me, in the sense that the app that crashed before does start now, and works as expected.

*But*, as the previous poster noticed, there are still error/warning messages.

One of the things that is breaking is the new global menu in Unity. On Ubuntu 32bit, the menu of my app is automagically brought to the top bar (I didn't do anything for it to happen). But on Ubuntu 64bit, my (32bit) app doesn't have a global menu, it is still inside the main window of the app. I guess the warning about libappmenu is the cause here.

Revision history for this message
abinadi (elseco) wrote :

Workaround 2 worked for me perfectly to get images in RealStudio 2011 r1 working in Ubuntu 11.04 64bit. So many thanks to Hadmut Danisch.

Revision history for this message
Jacob Appelbaum (jacob-appelbaum) wrote :

I found that IDA Pro 6.0 worked fine on the previous version of Ubuntu but on 11.04, I had to write a wrapper to work around this bug:

cat idaq64.sh
#!/bin/bash
export GDK_PIXBUF_MODULE_FILE=/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache
~/bin/ida/idaq64

This seems allow IDA Pro to launch but IDA Python is busted. That's a step forward but it's not really usable. This bug will keep me from using 11.04 and future versions of Ubuntu with IDA Pro.

Revision history for this message
Jacob Appelbaum (jacob-appelbaum) wrote :

I've found that it's is simpler and more stable to build a 32bit Maverick chroot with a few bind mounts for running IDA Pro.

Revision history for this message
Steve Langasek (vorlon) wrote :

The issue as originally described should no longer be present in Ubuntu Oneiric, since /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so will no longer exist: it has transitioned to the multiarch directory precisely because of problems like this.

As such, it should be possible to avoid this problem in oneiric by installing libgdk-pixbuf2.0-0:i386.

This will still give somewhat mixed results until the ia32-libs stack has been completely superseded by multiarch library builds. If you have specific 32-bit applications you're trying to run and can provide a list of the 32-bit libraries they need, we can factor those into the multiarch conversion roadmap.

Revision history for this message
Hadmut Danisch (hadmut) wrote :

I currently can't check this.

I have only one computer (a 32bit machine) under oneiric and still so much trouble with it that I don't dare to move one of my bigger 64 bit machines to oneiric.

However, I would see the mail problem that the path /usr/lib is ambiguous.

If I understand that correcty, all 32 bit libs will be under /usr/lib/i386-linux-gnu and so on in future. That sounds good.

The commercial program, that raised my problems, seems to work in the 32 bit version, however.

Revision history for this message
Scott Ritchie (scottritchie) wrote :

ia32-libs currently ships gdk-pixbuf for a few apps, would it be beneficial to have a symlink from

/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache.32 to /usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache ?

Revision history for this message
Lenz Grimmer (lenzgr) wrote :

This bug affects me as well. I stumled over it while trying to upload pictures to a web site that uses Flash for uploading multiple images. The file selection dialogue always disappeared when it tried to display image thumbnails. Starting opera with "GDK_PIXBUF_MODULE_FILE=/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache" set resolves the issue.

Revision history for this message
Hadmut Danisch (hadmut) wrote :

In my eyes, this is a general design bug. It should have never happend to use /usr/lib for both 32 and 64 bit specific libs (in ubuntu32 and ubuntu64), thus introducing ambiguity.

All architecture-dependent files should be restricted to /usr/lib32 and /usr/lib64. That way it would be easy to load 32-bit .debs into a 64-bit system and vice versa.

Revision history for this message
Rodrigo Garcia (rodrigopablogp) wrote :

Hi,

I'm running eclipse 3.5 32 bit with java 32 and I'm trying to run an SWT application I'm working on. I was using windows but I want to be able to do it from ubuntu, so I added the SWT jar for linux 32 bit

I've tried the workarounds suggested here so I'm using the following script to run eclipse:

export UBUNTU_MENUPROXY=0
export GDK_PIXBUF_MODULE_FILE=/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache
/home/rodrigo/Apps/eclipse_jee_galileo_lvs/eclipse

Then, when I try to run my app I get the following errors:

(SWT:3242): Gtk-WARNING **: Loading IM context type 'ibus' failed

(SWT:3242): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/immodules/im-ibus.so: wrong ELF class: ELFCLASS64

(SWT:3242): Gtk-WARNING **: Loading IM context type 'ibus' failed
Exception in thread "main" java.lang.RuntimeException: java.lang.NullPointerException
 at com.lvsint.abp.admin.AbpApplicationLauncher.launch(AbpApplicationLauncher.java:61)
 at com.lvsint.abp.richclient.eventcreator.EventCreatorShell.main(EventCreatorShell.java:2237)
Caused by: java.lang.NullPointerException
 at org.eclipse.swt.accessibility.Accessible.isValidThread(Unknown Source)

Does anybody know how to fix this problem?
Thanks

Revision history for this message
thejudge (judgejules04) wrote :

:~$ GDK_PIXBUF_MODULE_FILE=/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache bibble5

works for me

Revision history for this message
Jesse Glick (jesse-glick) wrote :

Possibly related: if you download JDK 6u29 or 7u1 from java.sun.com and pick the 32-bit version (.tar.gz), with ia32-libs-multiarch:i386 and thus ia32-libs installed, and run .../jdk/bin/java -jar .../jdk/demo/jfc/SwingSet2/SwingSet2.jar, then from the Look & Feel menu select GTK, you get errors on console

/usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so: wrong ELF class: ELFCLASS64
(java:12345): Gtk-WARNING **: Failed to load type module: /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so

though they do not seem to be fatal. Overriding GDK_PIXBUF_MODULE_FILE does not help. strace -f reveals the process trying plausible locations such as /usr/lib/i386-linux-gnu/gtk-2.0/menuproxies/libappmenu.so first, but nothing is found there, and then it finds the 64-bit lib in a generic location. This seems to be a bug in the appmenu-gtk package. Bug #783155 and bug #783073 seem related.

Revision history for this message
Jesse Glick (jesse-glick) wrote :

Also from Java (but not sure how to reproduce):

/usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so

Revision history for this message
Calvin Mitchell (calvin674) wrote :

To Jesse-Glick: There might be an env var to point to the libgvfsdbus in lib32 like there was for gdk-pixbuf (GDK_PIXBUF_MODULE_FILE).

Revision history for this message
Steve Langasek (vorlon) wrote :

> This will still give somewhat mixed results until the
> ia32-libs stack has been completely superseded by
> multiarch library builds.

This has now happened. In precise and beyond, there should be no gio modules in the non-architecture-qualified paths.

Changed in ia32-libs (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.