It looks like libsigc++-2.6 need reverse deps to use -std=c++11 The rest of distributions are simply appending that flags to the packages
Could we get a standard snipplet? Is this what you are thinking off? + if has_version \>=dev-libs/libsigc++-2.6 ; then + append-cxxflags -std=c++11 + fi
Would it cause issues to append it always instead of with the conditional? (that is the road other distros chose... but maybe because they only care about the latest version) Also, I wonder if maybe some package depending on glibmm but not on libsigc++ would also exhibit the issue and then would need to use a different snipped
Also looks like Fedora and Ubuntu, after starting to apply this changes, simnply moved to gcc5 widely that uses -std=c++11 by default https://lists.ubuntu.com/archives/ubuntu-devel/2015-July/038825.html On the other hand, Debian opted for patching their glibmm to append the flag via pkgconfig files: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800371 https://bugzilla.gnome.org/show_bug.cgi?id=755750 Maybe we could try the Debian approach as I am unknown when will we be ready for gcc5
@toolchain, what gcc version will start to default to -std=c++11? Maybe we should simply decrease the keywording of dev-libs/libsigc++-2.6 to the same level as that gcc version and try to keyword/stabilize it when that gcc version is ready to be stabilized The affected packages would be: >=dev-libs/libsigc++-2.6 >=dev-cpp/cairomm-1.12 >=dev-cpp/glibmm-2.46 >=dev-cpp/gtkmm-3.18 >=dev-cpp/pangomm-2.38 >=dev-cpp/atkmm-2.24 >=dev-cpp/gtksourceviewmm-3.18 The only issue I see is that, if having a gcc with -std=c++11 enabled will take a long time, we could start to have problems of new reverse deps needing to lose keywords with it and we would also miss the opportunity of fixing the reverse deps to be compatible with libsigc++-2.6 :/
5.1. Don't mess around waiting for GCC versions to go stable. The GCC version in stable has no bearing on what GCC version people are using. Just use -std=c++11.
@jlec, then, I don't mind using either the "unconditional" way or the other. If other people from gnome team doesn't have any concern, feel free to go ahead and thanks a lot for your help (this days it will be difficult to me for committing things :S) Thanks a lot
This is never this simple. C++11 can change the ABI. So the point kinda is, we need to ensure that all C++ libraries in a depgraph use the same C++ version.
(In reply to Michał Górny from comment #7) > This is never this simple. C++11 can change the ABI. So the point kinda is, > we need to ensure that all C++ libraries in a depgraph use the same C++ > version. This is pretty awful when you really think about it. I feel like I'm watching a train-wreck in super slow motion. I'm not sure we're taking this seriously enough -- sooner or later it seems destined to become a major clusterfuck if we don't do something proactive about it now while the drawing-board is relatively uncluttered. The only thing I can think of that has this kind of two-way depgraph magic property are the major "abi" USE_EXPAND values (multilib-build and python-r1, in other words). But those rely on fancy framework-generated USE-flag deps, which seem like overkill and likely to incur unjustifiable user-experience-costs. Perhaps a solution to this cxx11 clusterfuck can be found that works more like perl? By that I mean, pick your poison (respectively, your cxx11 ABI of preference or your major perl version of choice), rely on inbuilt portage features do the trick most of the time, and, when it breaks, run "magically-fix-everything.sh," grab a caffeinated beverage or three and fire up your favorite VOD client while the mess gets magically cleaned up by robots somehow.
(In reply to Gregory Turner from comment #8) > (In reply to Michał Górny from comment #7) > > This is never this simple. C++11 can change the ABI. So the point kinda is, > > we need to ensure that all C++ libraries in a depgraph use the same C++ > > version. > > This is pretty awful when you really think about it. I feel like I'm > watching a train-wreck in super slow motion. > > I'm not sure we're taking this seriously enough -- sooner or later it seems > destined to become a major clusterfuck if we don't do something proactive > about it now while the drawing-board is relatively uncluttered. > > The only thing I can think of that has this kind of two-way depgraph magic > property are the major "abi" USE_EXPAND values (multilib-build and > python-r1, in other words). > > But those rely on fancy framework-generated USE-flag deps, which seem like > overkill and likely to incur unjustifiable user-experience-costs. > > Perhaps a solution to this cxx11 clusterfuck can be found that works more > like perl? By that I mean, pick your poison (respectively, your cxx11 ABI > of preference or your major perl version of choice), rely on inbuilt portage > features do the trick most of the time, and, when it breaks, run > "magically-fix-everything.sh," grab a caffeinated beverage or three and fire > up your favorite VOD client while the mess gets magically cleaned up by > robots somehow. "proactive" is something gentoo never do. This is quite serious problem, and again, libsigc++ bumped, just of a matter of gnome-3.18 (cairomm) requirement without taking in acccount all reverse dependencies, and https://bugs.gentoo.org/show_bug.cgi?id=542482 (which has no good attacking plans to date). Now, "9 circles of hell" is what expected and "reactive" fixes. What should have happened, is NO gnome-3.18 updates, but it seems gentoo gnome never test systems outside of "gnome environment" But ok, stopping ranting --Matthew 7:6
Come on guys, this c++11 mess has been predicted for over a year already (as first reports came in from webkit-gtk, etc), just check the gentoo-dev archives and bugzilla. Yes the current situation sucks, no this is not the fault of the Gnome team, yes, sane and constructive discussion can go a long way and this is best directed to gentoo-dev mailing list for reviews and larger panel of c++ knowledgeable devs.
Exactly. And over that time, all discussions ended up with no good solution. Therefore, I don't think this one's going to be any better and I'd rather focus on fixing the existing breakage with the tools we have. Though it's your fault for keeping this known breakage unmasked for quite a while. It's rather clear that sigc++ revdeps need to enable some dialect of C++11. The question is whether to: A. Enable it independently of sigc++ version, or B. Enable it based on installed sigc++ version. I think A won't hurt much more and would be easier to do. But before you become lazy: don't append -std to pkg-config. Aside to it being non-portable, some packages may actually need gnu++11.
Yes, the downsides of appending the flags in .pc files are a bit explained in upstream bug report Then, I think we mostly agree on using "append-cxxflags -std=c++11" when possible and I would vote for making it unconditionally but if you prefer to make it conditional, I don't have any strong opinion against that Regarding the fault about not keeping it masked forever, in this case it was simply missed because of the way of bumping with apps at first and later libs to try to see if upstreamed forgot to update configure.ac version checks when bumping :/ Anyway, looking to other existing breakages in the tree (like boost, samba, apache...) looks like keeping things hardmasked or not bumped only help to delay things even more (sometimes years)
(In reply to Pacho Ramos from comment #4) > The affected packages would be: > >=dev-libs/libsigc++-2.6 > >=dev-cpp/cairomm-1.12 > >=dev-cpp/glibmm-2.46 > >=dev-cpp/gtkmm-3.18 > >=dev-cpp/pangomm-2.38 > >=dev-cpp/atkmm-2.24 > >=dev-cpp/gtksourceviewmm-3.18 @toralf, would you mind in helping us running a "stable" tinderbox with this packages keyworded to try to catch all the reverse deps that need to be fixed? Thanks a lot
Well, one more problem I see is adding c++11 checks everywhere. But maybe it's time to stop doing that and just let things fail the usual way.
(In reply to Pacho Ramos from comment #12) > Yes, the downsides of appending the flags in .pc files are a bit explained > in upstream bug report > > Then, I think we mostly agree on using "append-cxxflags -std=c++11" when > possible and I would vote for making it unconditionally but if you prefer to > make it conditional, I don't have any strong opinion against that This may get you into trouble since there is a depth to the linkage graph and you may need to push the -std=c++11 down further than just the immediate package. I can't be sure, this *may* work, but there is the distinct possibility that you'll get into trouble if this library further links against other libraries compiled with c++98 (ie the default for gcc-4.x). I'll be tinderboxing for what breaks if we add CXXFLAGS="-std=c++11" globally. I know there are problems with this approach, eg some packages might need gnu++11, but I think that fixing gnu++11 <=> c++11 incompatibility on a per package basis will be easier than fixing c++11 <=> c++98 incompatibilites. [There is still the other problem of c++11 <=> c++11 incompatibility when switching between versions of gcc-4.x/5.y but let's deal with that separately. There I'm going to propose an -Wl,-rpath= solution.] @pacho, if you are available sometime next week on irc, maybe you wan walk me through what profiles/pkgs need to be tested. I'll be using https://wiki.gentoo.org/wiki/Project:RelEng_GRS. > > Regarding the fault about not keeping it masked forever, in this case it was > simply missed because of the way of bumping with apps at first and later > libs to try to see if upstreamed forgot to update configure.ac version > checks when bumping :/ > > Anyway, looking to other existing breakages in the tree (like boost, samba, > apache...) looks like keeping things hardmasked or not bumped only help to > delay things even more (sometimes years) Yeah, this was going to hit us sooner or later. I sent out a news item for it, so did vapier. We just don't have good solutions in Gentoo because ${choice}. If we forced the version of gcc and the c++ abi then this problem would not exist.
(In reply to Ryan Hill from comment #5) > 5.1. Don't mess around waiting for GCC versions to go stable. The GCC > version in stable has no bearing on what GCC version people are using. > Just use -std=c++11. @Ryan, what do you think about just pushing out CXXFLAGS+="-std=c++11" globally? My understanding is that syntactially/semantically c++98 is a proper subset of c++11. It should work. If you think that's a good idea, what would be the best way of doing so? Via the profile make.defaults? Or gcc specs?
(In reply to Anthony Basile from comment #15) > (In reply to Pacho Ramos from comment #12) > > Yes, the downsides of appending the flags in .pc files are a bit explained > > in upstream bug report > > > > Then, I think we mostly agree on using "append-cxxflags -std=c++11" when > > possible and I would vote for making it unconditionally but if you prefer to > > make it conditional, I don't have any strong opinion against that > > This may get you into trouble since there is a depth to the linkage graph > and you may need to push the -std=c++11 down further than just the immediate > package. I can't be sure, this *may* work, but there is the distinct > possibility that you'll get into trouble if this library further links > against other libraries compiled with c++98 (ie the default for gcc-4.x). > > I'll be tinderboxing for what breaks if we add CXXFLAGS="-std=c++11" > globally. I know there are problems with this approach, eg some packages > might need gnu++11, but I think that fixing gnu++11 <=> c++11 > incompatibility on a per package basis will be easier than fixing c++11 <=> > c++98 incompatibilites. > > [There is still the other problem of c++11 <=> c++11 incompatibility when > switching between versions of gcc-4.x/5.y but let's deal with that > separately. There I'm going to propose an -Wl,-rpath= solution.] > > @pacho, if you are available sometime next week on irc, maybe you wan walk > me through what profiles/pkgs need to be tested. I'll be using > https://wiki.gentoo.org/wiki/Project:RelEng_GRS. Well, I don't plan to enable -std=c++11 globally, only for the applications using the mm libs, then, I doubt the breakage will extent to many more packages once the first "round" of failing reverse deps is fixed to append the flag (this is what was done in other distributions until they moved to gcc5... I am really unsure about how safe would be to enable -std=c++11 globally for gcc49 :/) Well, on that distributions (at least Ubuntu) maybe they took advantage of this for also moving to gcc5 as an opportunity to rebuild everything and also cope with the ABI break between gcc49 and gcc5... but I guess we won't be able to do that :|
Also, I guess the problem of appending it globally would be the same as appending it with .pc files: https://bugzilla.gnome.org/show_bug.cgi?id=755750#c4 I am unsure if we even have one package that would hit that problem... but maybe it's a bit risky :/
That's a wrong way forward. We simply shouldn't do that.
(In reply to Pacho Ramos from comment #13) > @toralf, would you mind in helping us running a "stable" tinderbox with this > packages keyworded to try to catch all the reverse deps that need to be > fixed? started : amd64-desktop-stable_20151201-184322 had to unmask few dep/blocker too : >=dev-libs/glib-2.46.2 >=dev-util/gdbus-codegen-2.44.1 >=x11-libs/gtk+-3.18.5 >=dev-libs/glib-2.46.2 >=x11-libs/pango-1.38.1 >=x11-libs/libXrandr-1.5.0 >=x11-proto/randrproto-1.5.0 >=x11-libs/gtksourceview-3.18.1 >=dev-libs/atk-2.18.0
One more note: since this is something upstream-enforced, I'd expect revdeps to slowly adapt C++11 in their buildsystems. Therefore, we should really track that and remove our hacks once upstream solves that.
(In reply to Michał Górny from comment #21) > One more note: since this is something upstream-enforced, I'd expect revdeps > to slowly adapt C++11 in their buildsystems. Therefore, we should really > track that and remove our hacks once upstream solves that. Don't get me wrong, if you can track all these revdeps down and contain them, then adding -std=c++11 on a per package basis is better than turning on c++11 globally. I'm still not sure what breaks if we do. I know the theory, but what happens in practice.
I believe there would be more packages broken by forcing -std=c++11 globally than there would be handling this on a per-package basis. We also have users that rely on compilers that don't support c++11 (pre 4.7 I think). I also would not want the standard changing in an already stable compiler series, meaning it doesn't really help us _right now_. I actually don't mind the .pc file thing, but I'm lazy. Up to you guys. :D It's probably more sensible to just fix things as they break. It'll be painful but it's the best option we have. As Michał points out, downstreams are going to have to fix their packages eventually. So just treat it like any other library breakage, and just hope we don't run into any abi conflicts.
OK, then, I think we mostly agree on appending: append-cxxflags -std=c++11 on broken apps. I would append it unconditionally as the upstream macro does (the upstream macro appends it as soon as a compiler with -std=c++11 support is available, as it's required now, and dies otherwise without checking for libsigc++/glibmm versions) https://git.gnome.org/browse/mm-common/commit/?id=0cb42dc92a380b2033f92bb7f31fc8a0dc0b278a https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html
(As a side note: Mageia is currently having gcc49 still, not like other major distributions that moved to gcc5 "hiding" this issue, and, then, you can also take a look to their .spec files to see how they solved the build issues for each package in the case you get further problems) https://svnweb.mageia.org/packages/cauldron/
I'll point out that no version of GCC will ever default to -std=c++11. Rather, the default is -std=gnu++11, which is what we ought to be discussing here. Specifying -std=c++11 actually disables certain GNU extensions that are enabled by default. This would cause breakage in projects that rely on those extensions. Also, I'll argue that globally switching to -std=gnu++11 (or -std=c++11) is a bad idea because C++11 adds new keywords to the language, which could cause syntax errors in older code that uses those keywords as identifiers.
attempting to apply any -std at a global level doesn't make sense imo and leads to way more pain than it actually fixes btw, gcc-5.3 is in ~arch now
add mangler to the list same errors
Debian folks analysis results: https://bugzilla.gnome.org/show_bug.cgi?id=755750#c9 Summary ------- 10 packages don't use pkg-config 6 packages include sigc++/object.h 2 packages include sigc++/class_slot.h 1 package uses the deleted sigc::is_base_and_derived<> class 1 package overrides -std=c++11 by adding the -ansi compiler option 1 package uses pkg-config when a C file is compiled, and then -std=c++11 is illegal 5 packages contain code which is illegal in C++11, but legal in older C++ 3 packages (possibly more) contain code which has become ambiguous as a result of more functions and classes being available in C++11 I know it's different from Gentoo...
(In reply to Pacho Ramos from comment #4) >The affected packages would be: > >=dev-libs/libsigc++-2.6 > >=dev-cpp/cairomm-1.12 > >=dev-cpp/glibmm-2.46 > >=dev-cpp/gtkmm-3.18 > >=dev-cpp/pangomm-2.38 > >=dev-cpp/atkmm-2.24 > >=dev-cpp/gtksourceviewmm-3.18 > I have ended on rebuilding all reverse deps of that packages, I tried to solve as much as I was able to but the remaining blockers here are harder to handle :S Any help with them will be highly appreciated
I confirm the issue, had to add -std=c++11 flag to CXXFLAGS for those packages in order to re-merge them on a PPC G4 machine. dev-cpp/libglademm and dev-cpp/gconfmm packages are also affected by this issue.
OK I guess we can close this as obsolete now. Also gcc-6 will go stable soon.