As mentioned here[1] the versions of libsexy and libsexymm in portage are not compatible with what Workstation 6.5 is compiled against and shipped with. The dependency on libsexy should be removed and possibly added as a blocker. [1] http://communities.vmware.com/message/1085845 Reproducible: Always Steps to Reproduce: 1. Emerge VMware Workstation 6.5 or greater. 2. Start Workstation and select "Create new VM". 3. Unmerge libsexy and libsexymm. 4. Repeat step 2. Actual Results: The Workstation UI crashes on step 2, but does not crash in step 4.
Hi Reilly, can you please check that this is an accessibility issue as in bug 235344 and bug 185444? Please emerge gtkmm (making sure that it either has no accessibility USE flag, or that USE="accessibility" is set, then emerge libview, libsexy and libsexymm. After that please let me know whether you're still experiencing the crashes...
(In reply to comment #1) > Please emerge gtkmm (making sure that it either has no accessibility USE flag, > or that USE="accessibility" is set, then emerge libview, libsexy and libsexymm. > After that please let me know whether you're still experiencing the crashes... I do not have the USE="accessibility" flag set. The only packages that respond to it (in emerge world -uDNva) are gtk-engines, gnome-themes, gdm, and gnome. Adding the flag causes them to pull in additional dependencies. I'm rebuilding now and will post the results.
It sounds like gtkmm doesn't have an accessibility USE flag (hence why I said "making sure that it either has no accessibility USE flag or ..."), so all you should need to do is now rebuild libsexy, libsexymm and libview, then test it. Thanks...
Rebuilding gtkmm, libview, libsexy, and libsexymm after running emerge world -uDNva with USE="accessibility" fixed the problem. Since none of those packages actually have this USE flag, what changed? Can this requirement be written into the vmware-workstation ebuild so this doesn't happen in the future?
Hiya, it wasn't enabling USE="accessibility" that did it. If you refer to the bugs I mentioned, gtkmm has now had accessibility permanently turned on. However, there's no real way to force a rebuild of these packages on other user's machines without a version bump of these packages, and even then user's might not have built the latest gtkmm. So the upshot is, yes it's a mess, but a relatively easy one to fix, so it's one we'll live with, and this is a duplicate...
*** This bug has been marked as a duplicate of bug 185444 ***
