This change in glib master does indeed break glibmm: http://git.gnome.org/browse/glib/commit/?id=d904612100120d12126f1a6623a106d8a5b02fa6 Unless it's really really necessary, it would be great if you would not do this, or if you could leave it until a glib ABI break.
Glib::Thread has a static (but private) GThread member instance: http://git.gnome.org/browse/glibmm/tree/glib/src/thread.hg#n285 so obviously glibmm no longer builds. We do this so you can cast a Glib::Thread* directly to a GThread*. We probably did this (in 2002?) because we have no way to associate our C++ instance with the C instance, because GThread is not a GObject. I doubt that we can find a way around that, though I have not tried. We also access the struct fields (joinable, priority) directly in simple getter methods, but I don't know if anybody really uses them. We might get away with breaking their functionality if we can't find replacements: http://git.gnome.org/browse/glibmm/tree/glib/src/thread.ccg#n120 http://git.gnome.org/browse/glibmm/tree/glib/src/thread.ccg#n135 At the least, we should probably deprecate those methods. I have no objection to deprecating our entire Glib::Thread API, if we can replace it with a more-correct Glib::Thread2 API, but we'll be in trouble if user applications (built with glibmm <= 2.30) start crashing just because the user installed glibmm 2.32. -- Murray Cumming murrayc@murrayc com www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
