In the gtkmm source file gtk/gtkmm/toolbar.cc, we have this: #define GTK_DISABLE_DEPRECATED and later, at 569 in the same source file, we have this: return Glib::wrap(gobj()->tooltips); At the same time in the gtk+-2.12.0-r2 include file, /usr/include/gtk-2.0/gtk/gtktoolbar.h for the definition of struct _GtkToolbar { ... we have this: ========================= #ifndef GTK_DISABLE_DEPRECATED GtkTooltips *tooltips; #else gpointer _tooltips; #endif ==================================== All of this leading eventually to: toolbar.cc:569: error: 'const struct _GtkToolbar' has no member named 'tooltips' This is a hard failure on both amd64 and sparc (by "hard" I mean it is built in to the source for gtkmm and apparently, into the include file as well). Looking at Bug 194277, I see that this builds with some version of gtk+, but I can't tell which (probably -2.10.14 because it is the stable version; gtk+-2.12.0-r2 is both ~amd64 and ~sparc, so this is not a problem for stable systems just now, so I am just flagging a problem coming along.) ARCH CC only for informational purposes at the moment.
I note that this is fixed in dev-cpp/gtkmm-2.12.0, so this is a problem only on systems where gtk+ is run unstable, but gtkmm is not. I would suggest fixing this in the ebuild for gtkmm-2.10.10 by forcing <gtk+-2.12 (Apparently, gtk+ and gtkmm things must all be stabilized in tandem, although this is not clear from the ebuilds.)
Due to this and other failures we introduced gtkmm-2.12 to the tree. They are at the same visibility level and the failure is compile time, therefore if you recompile gtkmm, you are supposed to get gtkmm-2.12 already, not ever gtkmm-2.10. Not sure why you are recompiling with the old version... I think adding a blocker in gtkmm would cause a cycle where you need to temporarily uninstall gtkmm before you are able to upgrade gtk+ to 2.12 when it finally goes stable, and that's not good and as they are supposed to be stabled together, I don't think a lack of one is any problem. However, if the only problem is that it defines GTK_DISABLE_DEPRECATED, maybe we can just patch it out and have it working. I thought there are other reasons why this didn't exactly work and just going 2.12 with gtkmm was the solution.
gtkmm-2.12 is the solution. I had already built gtk+-12.0-r2, because I run with gtk+ marked unstable. Then gtkmm wanted to upgrade from 2.10.9 to 2.10.10, and would not build with the gtk+-12 series. So I just marked gtkmm-12 and glibmm-2.14.0 to build unstable as well, and everything is happy. The problem is that gtkmm wanted to upgrade to a new stable version in the -2.10.10 series, and the ebuild did not block on gtk+-12 series. The sequence of events looks like this: Tue Aug 14 19:30:01 2007 >>> x11-libs/gtk+-2.10.14 Wed Aug 15 20:58:33 2007 >>> dev-cpp/gtkmm-2.10.9 Sun Sep 23 13:24:44 2007 >>> x11-libs/gtk+-2.12.0 Wed Sep 26 11:38:55 2007 >>> x11-libs/gtk+-2.12.0-r2 >>> Thu Oct 4 dev-cpp/gtkmm-2.10.10 FAILS <<<<< Thu Oct 4 12:27:42 2007 >>> dev-cpp/gtkmm-2.12.0 Since gtk+-2.12.0-r2 and gtkmm-2.12.10 are both marked unstable, it's probably enough not to let gtkmm-2.10.10 not try to build if gtk+ has gotten ahead of it.
Besides patching the *_DISABLE_DEPRECATED, I don't really know what to fix. The deps in all the ebuilds are correct...
(In reply to comment #4) > Besides patching the *_DISABLE_DEPRECATED, I don't really know what to fix. The > deps in all the ebuilds are correct... > I don't need a fix; I'm running gtkmm-2.12.10 & gtk+-2.12.0-r2, and that's all fine. The deps in gtkmm-2.10.10 are not quite correct, because it requires ">=x11-libs/gtk+-2.10.0" but to build, it also needs <x11-libs/gtk+-2.12.0 because of the DISABLE_DEPRECATED and tooltips. So It will try to build with a version of gtk+ it can't build with. That's all I've ever been saying. If you want to patch DISABLE_DEPRECATED, you need the same patch as gtkmm-2.12.10 uses, I think, because the comment on it implies that tooltips stuff is broken in gtk+-2.12.0. What gtkmm-2.12.10 does is (1) fix the error line to use _tooltips instead, and then (2) conditionally not compile it at all.
*** Bug 194956 has been marked as a duplicate of this bug. ***
You know, mixing stable ebuilds with ~arch deps is unsupported, so don't do it and you won't have issues. This bug is INVALID.
Well, I opened this just to pass on information. The DEPEND is still wrong, however you classify this. I didn't say ~arch/arch was a good idea; I said the ebuild is wrong. It is wrong.
This bug is valid and it is worth getting gtkmm-2.10 to compile against gtk+-2.12 to have less fuss when we get to stabling. gtk+-2.12 is supposed to be backwards compatible, and it is, so there is no reason with proper handling (read: small patching) of things it shouldn't build. However it's just not so bad if we don't manage doing so before it's time for gtk+-2.12 stabling.
amd64 has latest versions of both in stable -> removing CC, nothing left for us here
Fixed in stable, time to move on...
