GNOME Bugzilla – Bug 758798
Build failure: application.cc:287:27: error: virtual Gio::Application::~Application()' has a different exception specifier
Last modified: 2015-12-13 15:32:20 UTC
Created attachment 316467 [details] Build log Hi, While upgrading from GNOME 3.16 to 3.18 on Gentoo Linux ia64, glibmm 2.46.1 failed to compile with: /var/tmp/portage/dev-cpp/glibmm-2.46.1/work/glibmm-2.46.1/gio/giomm/application. cc:287:27: error: declaration of 'virtual Gio::Application::~Application()' has a different exception specifier In file included from /var/tmp/portage/dev-cpp/glibmm-2.46.1/work/glibmm-2.46.1/ gio/giomm/application.cc:6:0: /var/tmp/portage/dev-cpp/glibmm-2.46.1/work/glibmm-2.46.1/gio/giomm/application. h:236:11: error: from previous declaration 'virtual Gio::Application::~Applicati on() noexcept (true)' I was asked to report this upstream, so here is it. BTW, I'm trying to compile glibmm 2.46.1 with gcc 4.7. Is there a limitation on gcc version with glibmm 2.46.1? I found this gcc bug [1] that may be related. It's noteworthy that's a regression from previous glibmm 2.44.0. Please let me know how I can help further. Émeric [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56191
Thanks. This should fix that: https://git.gnome.org/browse/glibmm/commit/?id=6c7c14875d0f1d249abcccb0033297c8d48619dc It looks like a useful error message. I wonder why I don't see it myself with g++ 5.2.1.
(In reply to Murray Cumming from comment #1) > Thanks. This should fix that: > https://git.gnome.org/browse/glibmm/commit/ > ?id=6c7c14875d0f1d249abcccb0033297c8d48619dc Sorry for the late feedback, it take me some time to understand why this was still failing on Gentoo with your fix. Well, it's simply that Gentoo's glibmm ebuild doesn't invoke gmmproc to dynamically regenerate files in giomm/. These are statically packaged in glibmm ebuild, so giomm/application.cc was still buggy. Patching it the same way than src/application.ccg in Gentoo's glibmm ebuild did the trick. > It looks like a useful error message. I wonder why I don't see it myself > with g++ 5.2.1. Is it worth filing a bug against g++? Thanks, Émeric
Could this be backported to 2.46 branch to ensure upcoming versions get the fix too? Thanks
I have just released glibmm 2.46.3 with this fix.