As mentioned in bug 235344 comment 7, gtkmm unconditionally depends on gtk which unconditionally depends on atk, so there should never be a case where gtkmm is present but atk is not (at least for gtkmm-2.14). That means that the accessibility USE flag is simply toggling on and off the availability of the at-api. Given that nothing extra gets installed, there seems to be little point in turning off the accessibility USE flag. When it is turned off (by default) it causes problems for statically compiled programs that expect the at-api to be present (such as vmware). This shows up as a missing symbol problem for vmware in many of the Gentoo bug reports and forums. Checking for USE="accessibility" is easy to do in an ebuild, but checking that all dependent programs have been successfully recompiled against the now available API isn't (and libview needs to be recompiled otherwise the symbol errors still show up). The solution recommended on IRC and in the associated bug is to remove the accessibility USE flag. Please let me know if there's any problems with doing this, and we'll go off and have another think about it. Thanks... 5:)
I don't agree with such a change. Instead the ABI simply should not differ with or without, that is if gtkmm needs some kind of atkmm related class members or whatnot, there should at least be equally sized reserved variables in their place if atkmm is disabled, as to not break ABI at an object size level. This is assuming this is the problem here. While atk is an unconditional dependency of gtk+, that is not the case between atkmm and gtkmm - you only need atkmm if you have custom classes made in gtkmm that you want to add some more accessibility support than the used classes already provide (often nothing is needed if it's a composite class made of multiple standard GUI classes, etc). I'll try to investigate a bit deeper about the ABI difference in the following days. Please feel free to poke me on IRC (or here) if I haven't done that within a couple days.
I realize it's possible to turn off atkmm, but is there actually a point to it? It really seems pointless to me; just leave it on.
on or not, it is still an upstream problem that the ABI changes between a configure flag. That should be fixed anyway. And once that is done, there is no big problem with keeping atkmm conditional, provided that all the few users of it check for the USE flag or we split it to a separate package and they depend on that too.
(In reply to comment #3) > on or not, it is still an upstream problem that the ABI changes between a > configure flag. That should be fixed anyway. According to the Gtkmm documentation http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-optional-api.html the ABI is meant to change if the optional API(s) are disabled. This is to reduce "the overhead on reduced resources devices". > And once that is done, there is no > big problem with keeping atkmm conditional, provided that all the few users of > it check for the USE flag or we split it to a separate package and they depend > on that too. Atkmm is bundled with Gtkmm, and the default configuration is to build with Atkmm support. Building without Atkmm is probably only useful for the "reduced resources devices" mentioned above. Maybe this feature (disabling Atkmm) should be behind an internal USE flag, together with the other optional API/ABI features, rather than behind a global "accessibility" USE flag?
How about putting IUSE="+accessibility" ? @team, what say you? Cheers
Or USE=minimal? Either way is fine with me.
After discussion, I've decided to just add a warning for now. The problem is that forcing it on (or +accessability) causes breakage for anyone with it off (which is default in profiles). Forcing it off causes breakage for anyone with it on. So, I've just added a warning saying that if you change it, it will break things, and you need to re-emerge a bunch of stuff. If this can't be fixed so that ABI doesn't break, then we'll probably have to force it on, and deal with the one-time breakage for the majority of users.
(In reply to comment #7) > After discussion, I've decided to just add a warning for now. The problem is > that forcing it on (or +accessability) causes breakage for anyone with it off > (which is default in profiles). Forcing it off causes breakage for anyone with > it on. So, I've just added a warning saying that if you change it, it will > break things, and you need to re-emerge a bunch of stuff. > > If this can't be fixed so that ABI doesn't break, then we'll probably have to > force it on, and deal with the one-time breakage for the majority of users. As I said above, this API/ABI change is intentional. I don't think that it makes sense to place this configure flag behind a global "accessibility" USE flag. Maybe behind a local "atk[mm]" USE flag, which defaults to on? The break in ABI is unavoidable (although still painful, as the default up to now has arguably been incorrect), so I think that the change to a default enabling of the Atk API should happen soon, with a big fat warning about it too. Maybe this could happen with Gtkmm-2.14?
*** Bug 235473 has been marked as a duplicate of this bug. ***
what about pushing upstream a patch that would give different .so number/soname when atkmm is enabled/disabled (probably keeping the same number as it is now for when it is on)
I am the upstream maintainer of gtkmm. As I understand it, you don't (optionally) disable the use of ATK in GTK+, so why would you want to disable the use of atkmm in gtkmm? I suspect that you just used the --enable-api-atkmm option because you noticed it, and vaguely connected it to your system-wide "accessibility" flag. But that gtkmm configure option is not meant to be used by desktop packagers, and it obviously changes API and ABI. Just using it for the sake of it instead of solving a real problem is the kind of thing that gives gentoo a bad name. Please stop.
To be even more clear: It's one thing to disable certain user functionality (the screenreader, for instance). It's an entirely other thing to disable (or distort) part of the developer platform, such as not building ATK+ or atkmm.
(In reply to comment #11) > As I understand it, you don't (optionally) disable the use of ATK in GTK+, so > why would you want to disable the use of atkmm in gtkmm? > > I suspect that you just used the --enable-api-atkmm option because you noticed > it, and vaguely connected it to your system-wide "accessibility" flag. Honestly, the ebuilds have been like that for as long as I can remember and up until recently, we saw no need to change it. Not that the ebuilds were right, that's just how they were. > But that > gtkmm configure option is not meant to be used by desktop packagers, and it > obviously changes API and ABI. Just using it for the sake of it instead of > solving a real problem is the kind of thing that gives gentoo a bad name. > Please stop. (In reply to comment #12) > To be even more clear: It's one thing to disable certain user functionality > (the screenreader, for instance). It's an entirely other thing to disable (or > distort) part of the developer platform, such as not building ATK+ or atkmm. Thank you for clarifying what this option does, I've removed the accessibility USE flag from all our ebuilds and atkmm will now always be built. Let me say on behalf of the Gentoo devs involved here that there was no intention to break gtkmm or the Gnome developer platform, just a misunderstanding of how things should have been set up on our side. Cheers
Thanks.
This change broke deps for a few ebuilds: dev-util/crow-designer-2.13.0: nonsolvable depset(depends) keyword(~amd64) profile (default/linux/amd64/2008.0): solutions: [ dev-cpp/gtkmm[accessibility] ] media-sound/ardour-2.5-r1: nonsolvable depset(depends) keyword(~amd64) profile (default/linux/amd64/2008.0): solutions: [ >=dev-cpp/gtkmm-2.12.3[accessibility] ] media-sound/ardour-2.6.1_p4010: nonsolvable depset(depends) keyword(~amd64) profile (default/linux/amd64/2008.0): solutions: [ >=dev-cpp/gtkmm-2.12.3[accessibility] ] media-sound/ardour-2.7.1: nonsolvable depset(depends) keyword(~amd64) profile (default/linux/amd64/2008.0): solutions: [ >=dev-cpp/gtkmm-2.12.3[accessibility] ] media-sound/ardour-2.7_p4225: nonsolvable depset(depends) keyword(~amd64) profile (default/linux/amd64/2008.0): solutions: [ >=dev-cpp/gtkmm-2.12.3[accessibility] ] net-misc/amazonmp3-1.0.3-r2: nonsolvable depset(rdepends) keyword(~x86) profile (default/linux/x86/2008.0): solutions: [ dev-cpp/gtkmm:2.4[accessibility] ]
(In reply to comment #11) > I am the upstream maintainer of gtkmm. > > As I understand it, you don't (optionally) disable the use of ATK in GTK+, so > why would you want to disable the use of atkmm in gtkmm? > > I suspect that you just used the --enable-api-atkmm option because you noticed > it, and vaguely connected it to your system-wide "accessibility" flag. But that > gtkmm configure option is not meant to be used by desktop packagers, and it > obviously changes API and ABI. Just using it for the sake of it instead of > solving a real problem is the kind of thing that gives gentoo a bad name. > Please stop. (In reply to comment #12) > To be even more clear: It's one thing to disable certain user functionality > (the screenreader, for instance). It's an entirely other thing to disable (or > distort) part of the developer platform, such as not building ATK+ or atkmm. While I agree with those comments, please note that it is *upstream* responsibility to ensure that libraries with different abis are given a different soname. That we allowed that breakage in gentoo in one thing, that you knowingly allow(ed?) it upstream is much worse and you should really consider giving a different soname/.so number when atkmm is disabled to avoid further breakages and very hard to understand bug reports. (In reply to comment #15) > media-sound/ardour-2.5-r1: nonsolvable depset(depends) keyword(~amd64) profile > (default/linux/amd64/2008.0): solutions: [ > >=dev-cpp/gtkmm-2.12.3[accessibility] ] I just fixed ardour at least
(In reply to comment #16) > That we allowed that breakage in gentoo in one thing, that > you knowingly allow(ed?) it upstream is much worse and you should really > consider giving a different soname/.so number when atkmm is disabled to avoid > further breakages and very hard to understand bug reports. No, there are just too many combinations of reduced-api options (for embedded use) to make that realistic. It would make our build files insanely difficult to maintain, for a use case that just shouldn't happen. Reasonable patches welcome, of course, if you'd like to prove me wrong.
All the packages that needed atkmm have been fixed. Closing Thanks
