Summary: | dev-cpp/gtkmm-2.24.3 - In file included from xxx: /usr/include/gdkmm-2.4/gdkmm/xxx error: ‘GType’ does not name a type | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Yaron Tausky <yaron.tausky> |
Component: | Current packages | Assignee: | GNOME C++ Bindings Maintainers (OBSOLETE) <gnome-mm+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Adrian.Bassett, alexandref75, ao, dschridde+gentoobugs, erikdenstore+gbugs, harrisl, help, ivanhoe, jarausch, jason, Martin.vGagern, niks1024, pageexec, proteuss, vityokster, zeekec, ziapannocchia |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.gnome.org/show_bug.cgi?id=697835 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log for media-gfx/inkscape-0.48.4 |
Description
Yaron Tausky
2013-04-07 18:41:03 UTC
Same here. While looking for causes in emerge.log I saw gtkmm was updated to 2.24.3 on April 07. I masked it, returned to gtkmm 2.24.2 and inkscape compiled fine. Some missing include in the latest gtkmm? I see the same breakage when (re)building media-gfx/inkscape-0.48.4 with dev-cpp/gtkmm-2.24.3 . As in comment 1, downgrading to dev-cpp/gtkmm-2.24.2 let's the build succeed. *** Bug 465472 has been marked as a duplicate of this bug. *** Quoting bug #465472 comment #0: Comparing the color.h from the installed gtkmm 2.24.3 to the one from 2.24.2, I see this: --- …/gtkmm-2.24.2/image/usr/include/gdkmm-2.4/gdkmm/color.h +++ /usr/include/gdkmm-2.4/gdkmm/color.h @@ -8,3 +8,4 @@ -#include <glibmm.h> +#include <glibmm/ustring.h> +#include <sigc++/sigc++.h> @@ -55,5 +56,7 @@ typedef GdkColor BaseObjectType; +#endif /* DOXYGEN_SHOULD_SKIP_THIS */ + /** Get the GType for this class, for use with the underlying GObject type system. + */ static GType get_type() G_GNUC_CONST; -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ So the previous file did include the main glibmm header, which the new one does not. The fix would be having this header included again, either in the color.h from gtkmm or in the inkscape sources. Not wure which is more appropriate. I wrote a mail to the gtkmm-list requesting clarification whether this change is intended or accidential. Depending on that, either gtkmm or inkscape should be fixed, I believe. My message still awaits moderator approval, though. *** Bug 465156 has been marked as a duplicate of this bug. *** *** Bug 465318 has been marked as a duplicate of this bug. *** *** Bug 465624 has been marked as a duplicate of this bug. *** *** Bug 465660 has been marked as a duplicate of this bug. *** Upstream would like to see this patch checked: https://bugzilla.gnome.org/show_bug.cgi?id=697835#c4 (I can't just now :S) *** Bug 465726 has been marked as a duplicate of this bug. *** I strongly advise including the name Inkscape in bug title so that it shows up in the search for existing Inkscape bugs even though it's not actually an Inkscape bug. (In reply to comment #10) > Upstream would like to see this patch checked: > https://bugzilla.gnome.org/show_bug.cgi?id=697835#c4 > > (I can't just now :S) Those patches make gtkmm fail to emerge. I dropped them in /etc/portage and I get this: libtool: compile: x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I.. -I../.. -DG_LOG_DOMAIN=\"gdkmm\" -DGDKMM_BUILD=1 -pthread -pthread -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib64/pangomm-1.4/include -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -Wall -mtune=generic -mmmx -msse -msse2 -msse3 -mcx16 -msahf -O2 -pipe -c rgb.cc -fPIC -DPIC -o .libs/rgb.o 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 Do I report upstream or is this a gentoo-specific bug? this looks like an upstream bug *** Bug 468744 has been marked as a duplicate of this bug. *** *** Bug 464990 has been marked as a duplicate of this bug. *** Upstresam just released gtkmm-2.24.4 to take care of this problem: https://mail.gnome.org/archives/ftp-release-list/2013-June/msg00112.html Once we have that in portage, everything should be fine. At least in theory. +*gtkmm-2.24.4 (03 Jul 2013) + + 03 Jul 2013; Pacho Ramos <pacho@gentoo.org> +gtkmm-2.24.4.ebuild, + -gtkmm-2.24.3.ebuild, -gtkmm-3.8.0.ebuild: + Version bump, drop old and also broken version (#464994) + |