Heads up: glibmm/gtkmm now requires -std=c++11

[Kalev Lember]

Hi,

A quick heads up to anybody who might run into cryptic build errors when
building apps that use glibmm/gtkmm:

Latest glibmm/gtkmm stack in rawhide and F23 now uses C++11 features in
header files. This means when building other programs that use those
headers, the C++ compiler needs to be in C++11 mode now.

The fix is simple: make sure -std=c++11 is passed to the compiler.

It can be done in either in upstream build scripts or hacked in
downstream in spec files. I would usually always suggest to go for
upstreamable fixes, but I think in this case it's fine to do it
downstream as well. The reason is that the workaround is just a
temporary measure until GCC switches to use C++11 by default, which is
probably going to happen in F24 when GCC 6 lands.

Here's an example how to do it in a spec file:
http://pkgs.fedoraproject.org/cgit/inkscape.git/commit/?id=fc745c8687dd8a...

And here's how to do it in an upstreamable way:
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7a...
or
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6...

-- 
Kalev

[Mamoru TASAKA]

Kalev Lember wrote on 09/23/2015 09:35 AM:
>  Hi,
>
>  A quick heads up to anybody who might run into cryptic build errors when
>  building apps that use glibmm/gtkmm:
>
>  Latest glibmm/gtkmm stack in rawhide and F23 now uses C++11 features in
>  header files. This means when building other programs that use those
>  headers, the C++ compiler needs to be in C++11 mode now.
>
>  The fix is simple: make sure -std=c++11 is passed to the compiler.
>
>  It can be done in either in upstream build scripts or hacked in
>  downstream in spec files. I would usually always suggest to go for
>  upstreamable fixes, but I think in this case it's fine to do it
>  downstream as well. The reason is that the workaround is just a
>  temporary measure until GCC switches to use C++11 by default, which is
>  probably going to happen in F24 when GCC 6 lands.
>
>  Here's an example how to do it in a spec file:
>
> http://pkgs.fedoraproject.org/cgit/inkscape.git/commit/?id=fc745c8687dd8a...
>
>  And here's how to do it in an upstreamable way:
>
> https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7a...
>  or
>
> https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6...
Rather, can't be pkgconfig file in gtkmm30 modified for now to add -std=c++11
to Cflags?

Regards,
Mamoru

[Josh Stone]

On 09/22/2015 05:49 PM, Mamoru TASAKA wrote:
>  Kalev Lember wrote on 09/23/2015 09:35 AM:
> > Hi,
> >
> > A quick heads up to anybody who might run into cryptic build errors when
> > building apps that use glibmm/gtkmm:
> >
> > Latest glibmm/gtkmm stack in rawhide and F23 now uses C++11 features in
> > header files. This means when building other programs that use those
> > headers, the C++ compiler needs to be in C++11 mode now.
> >
> > The fix is simple: make sure -std=c++11 is passed to the compiler.
> >
> > It can be done in either in upstream build scripts or hacked in
> > downstream in spec files. I would usually always suggest to go for
> > upstreamable fixes, but I think in this case it's fine to do it
> > downstream as well. The reason is that the workaround is just a
> > temporary measure until GCC switches to use C++11 by default, which is
> > probably going to happen in F24 when GCC 6 lands.
> >
> > Here's an example how to do it in a spec file:
> >
> http://pkgs.fedoraproject.org/cgit/inkscape.git/commit/?id=fc745c8687dd8a...
> >
> > And here's how to do it in an upstreamable way:
> >
> https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7a...
> > or
> >
> https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6...
>  
>  Rather, can't be pkgconfig file in gtkmm30 modified for now to add -std=c++11
>  to Cflags? 
I'd guess that they really require *at least* c++11.

A project might instead choose gnu++11, c++14, gnu++14, etc.

[Kalev Lember]

On 09/23/2015 02:56 AM, Josh Stone wrote:
>  On 09/22/2015 05:49 PM, Mamoru TASAKA wrote:
> > Rather, can't be pkgconfig file in gtkmm30 modified for now to add -std=c++11
> > to Cflags?
>  
>  I'd guess that they really require *at least* c++11.
>  
>  A project might instead choose gnu++11, c++14, gnu++14, etc. 
Yes, agreed; I think that's a good reason why to not put it in the
pkgconfig file.

I am sure we'll sooner or later find a project that wants to support
another C++ dialect, such as C++14, and then if gtkmm30's pkgconfig file
overrides it, we'd a conflict between -std=c++11 and -std=c++14 and then
we'd have to back it out from the pkgconfig file and would be back to
square one :)

Good idea though, thanks!

-- 
Kalev

[Kevin Kofler]

Kalev Lember wrote:
>  The fix is simple: make sure -std=c++11 is passed to the compiler.
The default is gnu++98, so if you were using the default, you probably want 
gnu++11 instead. c++11 is strict C++11 without GNU extensions.

        Kevin Kofler