GNOME Bugzilla – Bug 697835
gtkmm-2.24.3 breaks builds because it requires different header includes.
Last modified: 2013-06-28 09:01:25 UTC
We get errors like: /usr/include/gdkmm-2.4/gdkmm/dragcontext.h:321:3: error: 'ListHandle_AtomString' in namespace 'Gdk' does not name a type In file included from document.cc:27:0: When building multiple reverse deps like inkscape, subtitleeditor...: https://bugs.gentoo.org/show_bug.cgi?id=464994 https://bugs.gentoo.org/show_bug.cgi?id=465156 https://bugs.gentoo.org/show_bug.cgi?id=465318
This change in the generated code, from here: https://bugs.gentoo.org/show_bug.cgi?id=464994 +++ /usr/include/gdkmm-2.4/gdkmm/color.h @@ -8,3 +8,4 @@ -#include <glibmm.h> +#include <glibmm/ustring.h> +#include <sigc++/sigc++.h> is due to the use of a newer gmmmproc (from newer glibmm). That is indeed unfortunate in a bug-fix release, and could be fixed by releasing a gtkmm 2.4 that was built with an older glibmm. I have no idea if that's what causes the error mentioned here.
I did the release.
The error in Comment 0 looks like the build errors I was having with gtkmm 2.24 before the 2.24.3 release. This is the commit in question: https://git.gnome.org/browse/gtkmm/commit/?h=gtkmm-2-24&id=42ca7d27e8dd3105d612f8330072416ec889447f
Created attachment 241370 [details] [review] Proposed patch Can you try this patch to 2.24.3 on you gentoo?
(In reply to comment #4) > Created an attachment (id=241370) [details] [review] > Proposed patch > > Can you try this patch to 2.24.3 on you gentoo? (Not on gentoo) I had to use --enable-maintainer-mode to get the files re-generated. Then I had to create a patch to fix some problem with gtk/widget.h (a deprecated signal causing problems I think due to the #ifndef ending up in the middle of the gtk-doc comment block). Then I had to work around the docs failing to build in maintainer mode: $ cp -r docs/reference/html __html_saved $ make || cp -nv __html_saved/* docs/reference/html/ && make After all that, the patch isn't sufficient to fix all the header problems. The first errors when attempting to build inkscape are: In file included from color-profile.cpp:9:0: /usr/include/gdkmm-2.4/gdkmm/color.h:61:10: error: 'GType' does not name a type In file included from color-profile.cpp:9:0: /usr/include/gdkmm-2.4/gdkmm/color.h:188:29: error: 'RefPtr' in namespace 'Glib' does not name a type /usr/include/gdkmm-2.4/gdkmm/color.h:188:35: error: ISO C++ forbids declaration of 'parameter' with no type [-fpermissive] /usr/include/gdkmm-2.4/gdkmm/color.h:188:41: error: expected ',' or '...' before '<' token /usr/include/gdkmm-2.4/gdkmm/color.h:241:9: error: 'ArrayHandle' in namespace 'Glib' does not name a type /usr/include/gdkmm-2.4/gdkmm/color.h:294:7: error: 'Value' is not a template /usr/include/gdkmm-2.4/gdkmm/color.h:294:51: error: expected template-name before '<' token /usr/include/gdkmm-2.4/gdkmm/color.h:294:51: error: expected '{' before '<' token /usr/include/gdkmm-2.4/gdkmm/color.h:294:51: error: expected unqualified-id before '<' token In file included from /usr/include/glibmm-2.4/glibmm/value.h:196:0, from /usr/include/glibmm-2.4/glibmm/propertyproxy_base.h:25, from /usr/include/glibmm-2.4/glibmm/propertyproxy.h:25, from /usr/include/glibmm-2.4/glibmm/objectbase.h:24, from /usr/include/glibmm-2.4/glibmm/wrap.h:26, from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:26, from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:23, from /usr/include/glibmm-2.4/glibmm/spawn.h:26, from ./io/sys.h:19, from color-profile.cpp:18: /usr/include/glibmm-2.4/glibmm/value_custom.h:109:7: error: 'Glib::Value' is not a template type /usr/include/glibmm-2.4/glibmm/value_custom.h:135:7: error: 'Value' is not a template
Created attachment 241394 [details] [review] work around some problem with gmmproc Work around for compilation error: In file included from ../gtkmm/container.h:30:0, from ../gtkmm/box.h:59, from ../gtkmm/dialog.h:31, from ../gtkmm/aboutdialog.h:31, from aboutdialog.cc:8: ../gtkmm/widget.h:4222:2: error: #endif without #if make[2]: *** [aboutdialog.lo] Error 1 make[2]: Leaving directory `/home/ejs/rpmbuild/BUILD/gtkmm-2.24.3/gtk/gtkmm'
Created attachment 241437 [details] [review] more header fixes More header fixes, enough to be able to compile inkscape 0.48.4 (when combined with both previous patches).
Ok, I'll look at these. Thanks !
Tried in gentoo, now emerge gtkmm-2.24.3 fails (due to the first "Proposed patch") with: In file included from ../gdkmm/region.h:67:0, from ../gdkmm/screen.h:33, from ../gdkmm/visual.h:32, from ../gdkmm/colormap.h:38, from ../gdkmm/rgb.h:23, from rgb.cc:21: ../gdkmm/types.h:358:9: error: 'ListHandle' in namespace 'Glib' does not name a type typedef Glib::ListHandle<std::string,AtomStringTraits> ListHandle_AtomString; ^ In file included from ../gdkmm/visual.h:32:0, from ../gdkmm/colormap.h:38, from ../gdkmm/rgb.h:23, from rgb.cc:21: ../gdkmm/screen.h:379:3: error: 'ListHandle' in namespace 'Glib' does not name a type Glib::ListHandle< Glib::RefPtr<Visual> > list_visuals(); ^ ../gdkmm/screen.h:388:3: error: 'ListHandle' in namespace 'Glib' does not name a type Glib::ListHandle< Glib::RefPtr<Window> > get_toplevel_windows(); ^ ../gdkmm/screen.h:616:3: error: 'ListHandle' in namespace 'Glib' does not name a type Glib::ListHandle< Glib::RefPtr<Window> > get_window_stack(); ^ make[2]: *** [rgb.lo] Error 1 Removing the first patch gtkmm compiles fine, but inkscape fails.
There are some messages on gtkmm-list concerning gtkmm 2.24.3: https://mail.gnome.org/archives/gtkmm-list/2013-April/msg00006.html https://mail.gnome.org/archives/gtkmm-list/2013-April/msg00007.html https://mail.gnome.org/archives/gtkmm-list/2013-April/msg00008.html The first of these messages contains a patch which I think is not mentioned in this bug. (Add #include <glibmm/error.h> in gdk/gdkmm/pixbuf.h, although it should be added to gdk/src/pixbuf.hg.) That patch is or is not necessary, depending on which version of glibmm you use. It's necessary with glibmm 2.32.0, but it's not necessary with the version of glibmm I pulled from the git repository on April 7.
I can confirm that for openSUSE, the collection of patches above fixes 'our' build of for example inkscape as well.
Great. I'll cook a final one for you to test, and then see about doing a 2.24.4 release. Thanks for the help.
Review of attachment 241394 [details] [review]: ::: gtkmm-2.24.3.orig/gtk/src/widget.hg @@ +993,3 @@ */ + _WRAP_SIGNAL(Glib::RefPtr<Atk::Object> get_accessible(), "get_accessible", ifdef GTKMM_ATKMM_ENABLED, refreturn) +#endif // GTKMM_DISABLE_DEPRECATED It was just said in the comment that putting a virtual function in ifdef isn't a good idea. And I agree.
Created attachment 242296 [details] [review] Proposed patch Combined the first and third patch. Can someone confirm it all work with it?
Comment on attachment 241394 [details] [review] work around some problem with gmmproc Marking as rejected. See comment 13.
Created attachment 242322 [details] [review] don't ifdef a signal The current tarball release does have that signal within #ifndef, the trouble is the current gmmproc puts the #ifndef within the doc comment block, like this: //Note that the deprecated keyword has no effect on _WRAP_SIGNAL() yet. //It doesn't seem like a good idea to put virtual functions in #ifdefs, because that would change the size of the class instances. /** @deprecated This should never have been in the API. It was never meaningful. * #ifndef GTKMM_DISABLE_DEPRECATED * @par Slot Prototype: * <tt>Glib::RefPtr<Atk::Object> on_my_%get_accessible()</tt> * */ Glib::SignalProxy0< Glib::RefPtr<Atk::Object> > signal_get_accessible(); #endif // GTKMM_DISABLE_DEPRECATED
This make more sense IMHO.
Using the attached patch in addition to the proposed above (comment 14) allows the current inkscape release version (0.48.4) as well as the current development version (bzr rev 12304) to build correctly on MacPorts, OS X 10.8.3. Note that this is using glibmm 2.34.1. Building with glibmm 2.36.0 has problems due to breakage in gmmproc as reported in bz 698989. It's possible that there are other missing glibmm includes that are not exposed by this testing. Continuing to test with other MacPorts ports that depend on gtkmm. Probably should be a thorough review of gtkmm to look for Glib::* usages without the corresponding includes before a new release is issued.
Created attachment 242614 [details] [review] Additional glibmm includes
Created attachment 243235 [details] headertest.sh The shell script headertest.sh compiles all header files, one at a time. The compiler generates error messages if a header file does not include all other header files that it depends on.
Created attachment 243236 [details] [review] patch: Add missing includes. This patch adds missing includes (mainly glibmm header files). It makes it possible to build and check gtkmm, and execute headertest.sh with no errors. Even with this patch there is no guarantee that all application programs that can be built with gtkmm 2.24.2 can be built. It's possible that an application program depends on some glibmm header file that it does not explicitly include, and that gtkmm does not depend on and does not include. I have used glibmm 2.32.0. It does not handle a deprecated signal the way it's described in comment 16. The generated code is //Note that the deprecated keyword has no effect on _WRAP_SIGNAL() yet. //It doesn't seem like a good idea to put virtual functions in #ifdefs, because that would change the size of the class instances. /** @deprecated This should never have been in the API. It was never meaningful. * * @par Slot Prototype: * <tt>Glib::RefPtr<Atk::Object> on_my_%get_accessible()</tt> * */ #ifndef GTKMM_DISABLE_DEPRECATED Glib::SignalProxy0< Glib::RefPtr<Atk::Object> > signal_get_accessible(); #endif // GTKMM_DISABLE_DEPRECATED
Created attachment 243277 [details] [review] patch: Add missing includes. Here's a smaller patch. I had copied more than necessary from gtkmm 3.0. It was a mistake to add #include <gtk/gtk.h> in gtk/src/enums.hg. It's not necessary, and it can be a problem when application programs are built.
Bug 700069 also concerns missing include files. If there will ever be another 2.24.x release of gtkmm, both these bugs should be fixed in it, IMO.
Disclaimer! Bug 700069 shall not be fixed in 2.24.x. See bug 700069 comment 3 and 4.
See also bug #700495 about a runtime problem with this release.
I have pushed a rewritten version of headertest.sh (comment 20) to glibmm/tools/test_scripts/testheaders.sh https://git.gnome.org/browse/glibmm/commit/?id=8cb94c761cfed43204d814d9494ed9ad98694193
*** Bug 700699 has been marked as a duplicate of this bug. ***
*** Bug 701321 has been marked as a duplicate of this bug. ***
What's the plan here, to roll a new gtkmm 2.24.4 release with older gmmmproc? I could volunteer to help do that.
Kalev, yes, please, that would be very helpful. Maybe we could test a tarball before we release it officially.
https://people.gnome.org/~klember/gtkmm-2.24.4.tar.bz2 , much appreciated if someone could give it a quick try.
Seems fine in my own testing, mind if I go ahead and release this? We'll surely get feedback then when distros pick it up. The diff to 2.24.2 looks good, only minimal changes in the generated code files. And inkskape builds fine with this release, again. I have a virtual machine set up with older glibmm, so if there's ever a need to roll another tarball in the future, I can easily do that.
Thanks for dealing with this.
Kalev, yes, please. If you have git commit rights, and gnome release access, please go ahead. Please don't forget to commit the ChangeLog and NEWS changes (that's all, right?) and tag the release.
All done, 2,24.4 is out: https://mail.gnome.org/archives/ftp-release-list/2013-June/msg00112.html