Tracker bug, please file individual bug reports and not discuss in this tracker
I wanted to add some more bugs but neither can I enter them here as "Depends on" nor can I block this bug from the others. So I list them here: bug 581996 bug 585376 bug 585378
If there is a suggested solution for these bugs, this would be a good place to document it.
I believe the solution would be similar to how dev-libs/libsigc++ was handled - add append-cxxflags -std=c++11 to revdeps, and then check those revdeps for breakage.
(In reply to Michael Palimaka (kensington) from comment #3) > I believe the solution would be similar to how dev-libs/libsigc++ was > handled - add append-cxxflags -std=c++11 to revdeps, and then check those > revdeps for breakage. Yes, that's acceptable I think. Even better, patch the build system (and code if it fails to build in c++11 mode) and send the resulting patch upstream. Note that some programs use GNU extensions, in that case -std=c++11 becomes -std=gnu++11. Ultimately, this in an upstream problem, so make sure you at least report the issue to them (and apply a workaround downstream asap while you wait for the official fix).
(In reply to Davide Pesavento from comment #4) > (In reply to Michael Palimaka (kensington) from comment #3) > > I believe the solution would be similar to how dev-libs/libsigc++ was > > handled - add append-cxxflags -std=c++11 to revdeps, and then check those > > revdeps for breakage. > > Yes, that's acceptable I think. Even better, patch the build system (and > code if it fails to build in c++11 mode) and send the resulting patch > upstream. Note that some programs use GNU extensions, in that case > -std=c++11 becomes -std=gnu++11. > +1, the latter is the only proper solution, if others are looking for some autotools code to copy; this is what was done and is already upstreamed in bug 587764
Or just declare gcc-6 stable. It defaults to -std=gnu++14...
I don't think that is feasible until more bugs from https://bugs.gentoo.org/show_bug.cgi?id=gcc-6 are fixed
I wonder if this could be handled through Qt's own build system support, namely the CMake configs it ships. These configs do set a bunch of compiler flags already, so maybe they should be patched to add -std=c++11 on a global level for everything using Qt via CMake? Then again, this may conflict with projects setting their own -std to something else. Not sure if this also could be checked for inside the CMake configs.
It should be noted that dev-qt/qt-docs-5.7.0_p1 isn't masked even though =dev-qt/assistant-5.7.0 is, meaning that, without intervention, that version of qt-docs will be installed on a system upgrade (on testing arches) and the latest unmasked version of assistant is left unable to automatically find any of the Qt documentation.
(In reply to rnddim from comment #9) > It should be noted that dev-qt/qt-docs-5.7.0_p1 isn't masked even though > =dev-qt/assistant-5.7.0 is, meaning that, without intervention, that version > of qt-docs will be installed on a system upgrade (on testing arches) and the > latest unmasked version of assistant is left unable to automatically find > any of the Qt documentation. =qt-docs-5.7* is now masked as well. Thanks.
I've eyeballed most of the revdeps (still need to look further into games-strategy/freeciv, media-plugins/mythplugins, media-tv/mythtv) and I think most failing packages should have bugs filed now.
Package dev-python/PyQt5-5.7 is not masked, and will not build without dev-qt/qtcore-5.7.0.
(In reply to Jeremy Stent from comment #12) > Package dev-python/PyQt5-5.7 is not masked, and will not build without > dev-qt/qtcore-5.7.0. This is quite off-topic. Please file a separate bug report.
Qt 5.7.1 is stable and all previous versions have been treecleaned. Time to close this tracker.
