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

Re: vmware-e.x.p.-15576 and Debian/Sarge/amd64

On 9/6/05, James D. Freels <freelsjd@ornl.gov> wrote:
Gdk: locale not supported by Xlib
Gdk: cannot set locale modifiers
Gdk: Error converting from UTF-8 to STRING: Could not open converter from 'UTF-8' to 'ISO-8859-1'
Gdk: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-1' is not supported
Using log file /tmp/vmware-fea/ui-19182.log
GLib: Cannot convert message: Conversion from character set 'UTF-8' to 'ISO-8859-1' is not supported

It seems that the application is linked against 32bit libraries, which resolve either against the libraries from libs-ia32 or against the libraries in your chroot, depending on ld.so.conf. In any case, these libraries try to load plugins from the normal directories, instead of the directories for the ia32 subsystem. Of course the normal directories contain 64bit plugins, so the load fails, and the plugin functionality is not available.

You can do
# ls /usr/lib/*/*.so
to get an overview of the potentially affected plugins. Lots of them. Basically, locales don't work (not in libc, not in X11, not in glib), image/icon loading does not work in libpixbufloader, and several gtk subsystems don't work.

Several possible solutions have been discussed here in the past (search for ia32-libs), but none has been implemented yet. Ubuntu has a package of ia32-libs with some "hacks" that make some of the plugins work. You can try that, it might just work. Otherwise, you can also configure most libraries to look for the plugins in a different, but that is a rather tedious process. I have posted a few times on relevant variables for this, if you want to go this route.

A hybrid system such as RedHat or SuSE will not show these issues, because the 32bit libraries are in the normal pathes.


Reply to: