Bug 245634 - glib 2.13 ABI breakage
glib 2.13 ABI breakage
Product: Fedora
Classification: Fedora
Component: glib2 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Denis Leroy
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-06-25 15:54 EDT by Tom London
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-03 11:46:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom London 2007-06-25 15:54:59 EDT
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:
[tbl@localhost ~]$ 

c++filt _ZN4Glib9ValueBase4initEm says:

[tbl@localhost ~]$ c++filt _ZN4Glib9ValueBase4initEm
Glib::ValueBase::init(unsigned long)
[tbl@localhost ~]$ 

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
_ZN4Glib9ValueBase4init; done
   799: 44b28c30    71 FUNC    GLOBAL DEFAULT   10 _ZN4Glib9ValueBase4initEP
  1050: 44b28c80    42 FUNC    GLOBAL DEFAULT   10 _ZN4Glib9ValueBase4initEj
   879: 00000000    42 FUNC    GLOBAL DEFAULT  UND _ZN4Glib9ValueBase4initEj
[root@localhost lib]# 

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

How reproducible:
Every time

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Denis Leroy 2007-06-26 06:38:15 EDT
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.
Comment 2 Tom London 2007-06-26 09:24:01 EDT
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?

Comment 3 Denis Leroy 2007-06-26 10:27:32 EDT
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.
Comment 4 Tom London 2007-06-26 10:36:04 EDT
OK.  Thanks.

I'll wait for your update before submitting this to VMWare.
Comment 5 Murray Cumming 2007-06-26 10:41:00 EDT
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.
Comment 6 Denis Leroy 2007-06-26 10:46:20 EDT
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.
Comment 7 Murray Cumming 2007-06-26 11:18:55 EDT
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.
Comment 8 Tom London 2007-07-03 11:46:39 EDT
This seems to work with glibmm24-2.13.6-3.fc8, and gtkmm24-2.11.3-2.fc8 


Note You need to log in before you can comment on or make changes to this bug.