gcc refuses to build sigc++ and glibmm with the -std=c++1z flag Version-Release number of selected component (if applicable): gcc version 7.0.1 20170309 (Red Hat 7.0.1-0.12) (GCC) glibmm24-2.50.0-2.fc26 libsigc++20-devel-2.10.0-2.fc26 How reproducible: Build anything with g++ -std=c++1z $(pkg-config --libs --cflags glibmm-2.4 sigc++-2.0) and #include <glibmm.h> Actual results: In file included from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:24:0, from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:23, from /usr/include/glibmm-2.4/glibmm.h:93, from test.cpp:1: /usr/include/glibmm-2.4/glibmm/variant.h:596:55: error: ISO C++1z does not allow dynamic exception specifications static V_CastTo cast_dynamic(const VariantBase& v) throw(std::bad_cast); ^~~~~ /usr/include/glibmm-2.4/glibmm/variant.h:643:1: error: ISO C++1z does not allow dynamic exception specifications throw(std::bad_cast) ^~~~~ /usr/include/glibmm-2.4/glibmm/variant.h:899:1: error: ISO C++1z does not allow dynamic exception specifications throw(std::bad_cast); ^~~~~ /usr/include/glibmm-2.4/glibmm/variant.h:1082:1: error: ISO C++1z does not allow dynamic exception specifications throw(std::bad_cast); ^~~~~ /usr/include/glibmm-2.4/glibmm/variant.h:1139:1: error: ISO C++1z does not allow dynamic exception specifications throw(std::bad_cast); With some other, more complex example, I get In file included from main.cpp:1: In file included from ./context.hpp:4: In file included from /usr/include/glibmm-2.4/glibmm.h:89: In file included from /usr/include/glibmm-2.4/glibmm/thread.h:50: In file included from /usr/include/sigc++-2.0/sigc++/sigc++.h:107: In file included from /usr/include/sigc++-2.0/sigc++/adaptors/adaptors.h:23: In file included from /usr/include/sigc++-2.0/sigc++/adaptors/bind.h:6: In file included from /usr/include/sigc++-2.0/sigc++/adaptors/bound_argument.h:24: In file included from /usr/include/sigc++-2.0/sigc++/reference_wrapper.h:22: In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/functional:60: In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/unordered_map:47: In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/hashtable.h:37: In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/node_handle.h:39: /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/optional:984:27: error: use of class template 'optional' requires template arguments template <typename _Tp> optional(_Tp) -> optional<_Tp>; ^ /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/optional:401:11: note: template is declared here class optional ^ /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/optional:984:40: error: expected ';' at end of declaration template <typename _Tp> optional(_Tp) -> optional<_Tp>; ^ /usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/optional:984:41: error: cannot use arrow operator on a type template <typename _Tp> optional(_Tp) -> optional<_Tp>;
That is not a GCC bug though. See http://gcc.gnu.org/gcc-7/porting_to.html or just don't enable C++17 support for code that is not valid C++17. As for the other message, as there are wrappers around STL headers, I'd think it is likely something in those wrappers is bogus too. If not, please provide a self-contained short testcase.
I see. Should I reassign this bug to the glibmm?
Well, C++17 has not been published yet, so it is up to the projects to choose what C++ version they are written in. But if the maintainer is willing to do anything with it, sure, reassign, otherwise it will be closed.
Ok, I think you can close this.
This is not something that should be patched in Fedora. Supporting C++17 is something that should be done upstream, not by patching every single header in glibmm, gtkmm and sigc++ in the Fedora packages. If you're using a C++11 or C++14 library that isn't compatible with C++17 then don't try to compile it as C++17. This is user error.
This makes sense: C++17 will remove support for old-style exception specifications, so we'd need some cleverness to support both the old and new ways in glibmm. I guess this will break lots of C++ code.
It should not break that much code, throw() is still supported in C++17 (albeit with slightly different meaning, it is now equivalent of noexcept), it is only the dynamic exception specification that has been removed, and that has been deprecated already since C++11.
I guess we would have dealt with it sooner if gcc had warned about it. We try to use just about every warning that the compilers have to offer.
Apparently fixing this doesn't break ABI, and it's only a problem in this one header, so I've fixed it and released it in glibmm 2.50.1. Patches are welcome if I have missed something.