FTBFS: warning: identifier 'noexcept' is a keyword in C++11 [-Wc++0x-compat]

[Philip Rinn]

Hi,

while subtitleeditor builds fine with glibmm2.4 version 2.44.0-1 [1] it fails with 2.45.40-0ubuntu1 [2].

The error is:

/usr/include/gtkmm-3.0/gtkmm/textiter.h:1231:5: error: 'exception_handlers_invoke' is not a member of 'Glib'

The diff between both versions of glibmm2.4 show some changes with 'exception_handlers_invoke' [3] so I suspect the error comes from this changes.

Best,
Philip

[1] https://launchpadlibrarian.net/212735989/buildlog_ubuntu-wily-amd64.subtitleeditor_0.52.1-1~ppa0_BUILDING.txt.gz
[2] https://launchpadlibrarian.net/212738226/buildlog_ubuntu-wily-amd64.subtitleeditor_0.52.1-1_BUILDING.txt.gz
[3] http://launchpadlibrarian.net/212362235/glibmm2.4_2.44.0-1_2.45.40-0ubuntu1.diff.gz

[Murray Cumming (murrayc)]

glibmm 2.45.40 requires C++11, both for its own build and by any apps that use it. gtkmm also now requires C++11.

I think you are seeing a symptom of building the application without C++11 support. For instance, using CXXFLAGS="--std=c++11", though you'd be better of using an m4 macro such as AX_CXX_COMPILE_STDCXX_11().

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package glibmm2.4 - 2.45.41-0ubuntu1

---------------
glibmm2.4 (2.45.41-0ubuntu1) wily; urgency=medium

  * New upstream release
    - Undeprecate HelperList and List_Iterator because gtkmm-2.4 uses these
      in its undeprecated API. (LP: #1478367)

 -- Robert Ancell <email address hidden> Tue, 28 Jul 2015 09:24:44 +1200

[Artur Rona (ari-tczew)]

@Robert Ancell
Thanks for uploading glibmm2.4 (2.45.41-0ubuntu1). Unfortunately subtitleeditor still got FTBFS.

https://launchpadlibrarian.net/212903208/buildlog_ubuntu-wily-amd64.subtitleeditor_0.52.1-1_BUILDING.txt.gz

I had to re-open this bug.

[Murray Cumming (murrayc)]

This is the build error now:

/usr/include/glibmm-2.4/glibmm/exception.h:34:3: warning: identifier 'noexcept' is a keyword in C++11 [-Wc++0x-compat]
   virtual ~Exception() noexcept = 0;

Like I said, glibmm now requires C++11:
https://bugs.launchpad.net/ubuntu/+source/glibmm2.4/+bug/1478367/comments/1

[Philip Rinn (rinni)]

No, the build of subtitleeditor fails because of:

/usr/include/glibmm-2.4/glibmm/exception.h:34:22: error: expected ';' at end of member declaration
   virtual ~Exception() noexcept = 0;

[Murray Cumming (murrayc)]

Yes, it's the compiler errors that are actually what stop the builds, but the warnings and errors are all part of the same problem: This app needs to be built with --std=c++11 when building against newer glibmm/gtkmm.

[Artur Rona (ari-tczew)]

I just added CXXFLAGS += --std=c++11 to debian/rules and it still fails to build.
Full buildlog: https://launchpadlibrarian.net/213050941/buildlog_ubuntu-wily-amd64.subtitleeditor_0.52.1-1~ppa2_BUILDING.txt.gz

Any another solutions?

[Philip Rinn (rinni)]

Hi Artur,

could you try upstreams patch?

http://gna.org/bugs/?23714

I will not have time to test before the weekend.

[TomasHnyk (sup)]

Any news on this? It would be unfortunate if subtitleeditor were not included in 15.10.

[Philip Rinn (rinni)]

glibmm2.4 war reverted to version 2.44.0 so subtitleeditor builds fine and should be included in 15.10

[Murray Cumming (murrayc)]

> glibmm2.4 war reverted to version 2.44.0

Any idea why? Nobody from Ubuntu has contacted us (the glibmm maintainers).

[Artur Rona (ari-tczew)]

subtitleeditor already builds fine.

 Removal requested on 2015-08-16.
Deleted on 2015-08-17 by Ubuntu Archive Robot

moved to release

[Murray Cumming (murrayc)]

Ah, I see this in the debian/changelog file for the glibmm package:

glibmm2.4 (2.45.41.is.2.44.0-0ubuntu1) wily; urgency=medium

  * Revert 2.45 update - it requires everything to be built using C++11

 -- Robert Ancell <email address hidden> Fri, 31 Jul 2015 15:46:18 +1200

I don't understand that and I wish someone had actually talked to upstream glibmm. The need for C++11 at compile time has no effect whatsoever on already-built applications and is easy to deal with when building applications. The next version of gcc will actually use C++11 by default.

[Robert Ancell (robert-ancell)]

Hi Murray,

All packages that use glibmm would be required to be updated in Ubuntu to build with C++11 for this transition (while existing packages worked fine all packages need to be able to be rebuilt). This was a much more work than I had initially expected and since a number of these packages are taken directly from Debian this would require us to diverge the packaging to complete this. For this reason the transition was too large to be completed in 15.10 and we will look at doing it in 16.04. Hopefully Debian will make the transition at the same time and it will be less changes required in Ubuntu.

[Murray Cumming (murrayc)]

> All packages that use glibmm would be required to be updated in Ubuntu to build with C++11 for this transition

It's the libstdc++ ABI break that causes the need for apps to be rebuilt. glibmm using C++11 in its API should not require anything to be rebuilt, and we'd definitely like to know if it does. I wouldn't call use of C++11 a transition.

It's inconvenient for you that the ABI break (libstdc++) and API change (glibmm using C++11) happened at around the same time in Ubuntu, but now that you've now managed to rebuild (because of the libstdc++ ABI break), for instance, subtitleeditor, with glibmm 2.44 (without C++11), updating glibmm to 2.45/46 should have no effect whatsoever on how well the already-built subtitleeditor works.

[TomasHnyk (sup)]

(I am not an insider, but what if one needed to issue a security patch for subtitleeditor once 15.10 is released? The package would fail to rebuild, which does not seem acceptable.)

[Murray Cumming (murrayc)]

Sure, that would be a good reason, yes. Though you wouldn't even know of it without the libstdc++ ABI break.

I just don't want people to think that we (glibmm, gtkmm) broke ABI when we didn't.

[Robert Ancell (robert-ancell)]

We do rebuild the whole archive [1] before release so updating while updating glibmm now would not cause anything to break due to ABI all the packages that build against it and don't use C++11 would be marked FTBFS (fails to build from source).

Note that only glibmm could be updated since we have the latest glib. The rest of the mm stack would have to be running the pre-C++11 versions. It will probably be easier to update everything in 16.04.

[1] http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150202-vivid.html