Bug 245634
| Summary: | glib 2.13 ABI breakage | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom London <selinux> |
| Component: | glib2 | Assignee: | Denis Leroy <denis> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | mclasen, mtasaka |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-07-03 15:46:39 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tom London
2007-06-25 19:54:59 UTC
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..... |