Hide Forgot
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: _ZN4Glib9ValueBase4initEm [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 libatkmm-1.6.so.1 libcairomm-1.0.so.1 libgdkmm-2.4.so.1 libglibmm-2.4.so.1 799: 44b28c30 71 FUNC GLOBAL DEFAULT 10 _ZN4Glib9ValueBase4initEP 1050: 44b28c80 42 FUNC GLOBAL DEFAULT 10 _ZN4Glib9ValueBase4initEj libglibmm_generate_extra_defs-2.4.so.1 libgtkmm-2.4.so.1 879: 00000000 42 FUNC GLOBAL DEFAULT UND _ZN4Glib9ValueBase4initEj libpangomm-1.4.so.1 [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): gtkmm24-2.11.3-1.fc8 How reproducible: Every time Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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 libraries. That sound about right? Thanks, tom
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.
OK. Thanks. I'll wait for your update before submitting this to VMWare.
This is caused by an ABI break in glib 2.13: http://mail.gnome.org/archives/gtk-devel-list/2007-June/msg00266.html 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 Closing.....