Red Hat Bugzilla – Bug 245634
glib 2.13 ABI breakage
Last modified: 2007-11-30 17:12:08 EST
Description of problem:
[tbl@localhost ~]$ vmware
/usr/lib/vmware/bin/vmware: symbol lookup error:
/usr/lib/vmware/lib/libvmwareui.so.0/libvmwareui.so.0: undefined symbol:
c++filt _ZN4Glib9ValueBase4initEm says:
[tbl@localhost ~]$ c++filt _ZN4Glib9ValueBase4initEm
But current package doesn't provide Glib::ValueBase::init(unsigned long);
instead it seems to provide Glib::ValueBase::init(unsigned int)
[root@localhost lib]# for i in lib*mm*.1; do echo $i; readelf -s $i | grep
799: 44b28c30 71 FUNC GLOBAL DEFAULT 10 _ZN4Glib9ValueBase4initEP
1050: 44b28c80 42 FUNC GLOBAL DEFAULT 10 _ZN4Glib9ValueBase4initEj
879: 00000000 42 FUNC GLOBAL DEFAULT UND _ZN4Glib9ValueBase4initEj
[BTW, 'c++filt _ZN4Glib9ValueBase4initEP' says '_ZN4Glib9ValueBase4initEP'...]
Not sure if this is a VMWare issue or Fedora. Guidance?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This is for rawhide yes ? I pushed new unstable gtkmm and glibmm to match the
glib2 and gtk2 versions. I thought VMWare shipped their own versions of gtkmm
(which is why vmware is a script that sets LD_LIBRARY_PATH) ?
Either way, I can't deal with this, VMWare is closed-source so I can't fix their
stuff. You can file a bug on their website, or on their forums, they're usually
very responsive. I have several contacts there as well if that can help.
Agree and understand.
I have no problems filing this against VMWare (I've been active getting other
Fedora related items 'fixed').
I can get VMWare running by forcing it to use their own version of gtkmm as you say.
Here is what I understand and what I will push into VMWare; please correct if I
have this cockeyed.
1. Rawhide is now shipping new versions of glib2, gtk2, and recently, new
versions of gtkmm and glibmm.
2. These newer versions change the allowed parameter (at least for i386) for
Glib::ValueBase::init() from '(unsigned long)' to '(unsigned int)'.
3. VMWare needs to update the libraries to match, or correct the 'algorithm'
they use to 'guess' a setting for 'VMWARE_USE_SHIPPED_GTK' to match the new
That sound about right?
Hold on a second here.
1. glibmm 2.13 is still the 2.4 binary API, so it's very much supposed to be
binary compatible with glibmm 2.12. I just posted on the gtkmm-list about this,
expect an update very shortly.
2. There's something wrong with VMWare's "/usr/bin/vmware" script. It apparently
tries to link with the installed glibmm rather that the version they shipped.
Maybe it is intentional, but I doubt it. That should be reported to them.
I'll wait for your update before submitting this to VMWare.
This is caused by an ABI break in glib 2.13:
They have fixed it in svn, but have not yet released a new tarball. Ubuntu are
patching their glib 2.13 while they wait for that.
When you fix or revert glib 2.13 to unbreak the ABI, you will need to rebuild
glibmm and any other C++ stuff above glib.
Collision! ok, thanks for the update Murray. I'll ping our glib2 maintainer, but
since this is rawhide, i might be tempted to wait until glib2 (and glibmm) come
out of unstable.
So point 1 above is definitely not VMware's fault. Point 2 though is still a
good question to ask them.
You really want to test unstable glib and GTK+ as much as possible while they
are unstable, not after it's too late to fix them. It even finds problems like
these (though Ubuntu Gutsy found it first this time). I think that's the purpose
of Rawhide, though I'm not sure.
This seems to work with glibmm24-2.13.6-3.fc8, and gtkmm24-2.11.3-2.fc8