GNOME Bugzilla – Bug 752797
gtkmm-2.24 Box API uses deprecated Glib::HelperList
Last modified: 2015-07-24 08:54:26 UTC
As noted by Jonathan Wakely - https://lists.fedoraproject.org/pipermail/devel/2015-July/212646.html - gtkmm-2.4/gtkmm/box.h uses Glib::HelperList . That was deprecated in glibmm 2.45.3: https://git.gnome.org/browse/glibmm/commit/?id=08c6cc2ca8dfdab8c1294bc925ea31df0b6ff8ff so when you build something that sets GLIBMM_DISABLE_DEPRECATED and uses gtkmm 2.4 - in the case we found, inkscape - it blows up. As it often does for GTK_DISABLE_DEPRECATED and GDK_DISABLE_DEPRECATED (including right in box itself), could gtkmm 2.4 temporarily undef GLIBMM_DISABLE_DEPRECATED before using the deprecated function?
(In reply to Adam Williamson from comment #0) > so when you build something that sets GLIBMM_DISABLE_DEPRECATED and uses > gtkmm 2.4 - in the case we found, inkscape - it blows up. You mean, doesn't compile, rather than blows up, right? This is not a runtime problem? Inkscape should not be defining GLIBMM_DISABLE_DEPRECATED in regular tarball builds. Disabling deprecated API for packagers just causes problems for packagers. This is like enabling -Werror for tarball builds. If Inkscape doesn't already have a way to avoid making it harder to build tarballs, it could do what the *mm projects do, using MM_ARG_ENABLE_WARNINGS. I'll take a look at doing what you suggest, just to fix the gtkmm-2.24 build with GLIBMM_DISABLE_DEPRECATED, but gtkmm-2.24 is really not supported and Inkscape should really not still be using it anyway. Note that newer versions of glibmm also require C++11 (CXXFLAGS="--std=c++11") and there's a good chance that we'll remove HelperList completely (an API change, not an ABI change).
"You mean, doesn't compile, rather than blows up, right? This is not a runtime problem?" Yeah, sorry, it's the compile process that blows up. "Inkscape should not be defining GLIBMM_DISABLE_DEPRECATED in regular tarball builds. Disabling deprecated API for packagers just causes problems for packagers. This is like enabling -Werror for tarball builds. If Inkscape doesn't already have a way to avoid making it harder to build tarballs, it could do what the *mm projects do, using MM_ARG_ENABLE_WARNINGS." inkscape does provide a parameter to configure to avoid the DISABLE_DEPRECATED stuff (--disable-strict-build). I've done Fedora builds using that parameter, now. It's not the default, though, you still have to find it. They do also already have some conditionals in there to avoid some DISABLE_DEPRECATED flags if a particular version of something is found, so they could extend that to do the same if glibmm is new enough. I just wasn't sure who would want to change what, so I figured I'd report the situation. "gtkmm-2.24 is really not supported and Inkscape should really not still be using it anyway." From what I can tell they're working on a GTK+ 3 port but it's still considered 'experimental' (that's according to people who've actually used it). Will it be possible to keep gtkmm-2.24 usable in some sense if HelperList is entirely removed from glibmm? If not, well, I guess their GTK+ 3 port gets more urgent...
(In reply to Adam Williamson from comment #2) > Will it be possible to keep gtkmm-2.24 usable in some sense if HelperList is > entirely removed from glibmm No. I'll try to avoid unnecessary disruption but I also don't want to waste time supporting ancient gtkmm-2.24.
I have undeprecated HelperList in glibmm: https://git.gnome.org/browse/glibmm/commit/?id=7d2e6b84c6e4e5a371887f98f42b56aaf94834ab And I have release glibmm 2.45.41 with that. However: 1. These newer versions of glibmm require applications to use --std=c++11 so now you have that problem too. You might be lucky. 2. Please stop using gtkmm-2.24.