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=fc745c8687dd8a362...
And here's how to do it in an upstreamable way: https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7acc7... or https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6a48...
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=fc745c8687dd8a362...
And here's how to do it in an upstreamable way: https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7acc7... or https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6a48...
Rather, can't be pkgconfig file in gtkmm30 modified for now to add -std=c++11 to Cflags?
Regards, Mamoru
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=fc745c8687dd8a362...
And here's how to do it in an upstreamable way: https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7acc7... or https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6a48...
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.
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!
-
Josh Stone -
Kalev Lember -
Kevin Kofler -
Mamoru TASAKA