GNOME Bugzilla – Bug 755750
C++11 features in headers but no -std=c++11 in pkg-config
Last modified: 2017-08-11 11:57:43 UTC
Bug-Debian: https://bugs.debian.org/800371 glibmm2.4 version 2.46.1-1 started to use C++11 features in the headers it exports, but pkg-config --cflags doesn't return -std=c++11. Given the default is still -std=gnu++98 in GCC 5, it causes packages which use these headers to fails to build. A build log showing the issue can be found here: https://buildd.debian.org/status/fetch.php?pkg=inkscape&arch=mips64el&ver=0.91-5%2Bb1&stamp=1443446208 I suspect other packages of the *MM stack are affected as well, since they were also switched over to use C++11 features.
Created attachment 312369 [details] [review] libsigc++ patch: sigc++-2.0.pc: Add -std=c++11 to cflags if necessary If -std=c++11 is added to libsigc++'s .pc file, it affects all packages that depend on libsigc++. That includes all *mm packages, doesn't it? An alternative would be to add an AC_SUBST() macro to MM_AX_CXX_COMPILE_STDCXX_11() instead of adding it to libsigc++2/configure.ac. Even with this patch it's possible that some packages will fail to build without modifying their compiler options. E.g. g++'s -ansi option can't be combined with -std=c++11. And packages that use any of the API that has been removed from libsigc++, will not build.
In the original Debian bug, https://bugs.debian.org/800371, there is now some doubt whether including -std=c++11 in the .pc file is the best solution. Shall we await the final conclusion of that discussion before my patch is pushed or rejected?
Fedora [https://lists.fedoraproject.org/pipermail/devel/2015-September/214928.html] thinks adding the flag to the pc file isn't the best either.
The problem, as I understand it: Gtkmm, glibmm and other mm packages require at least -std=c++11 when applications are built with g++. Most applications would benefit, if the output from `pkg-config --cflags gtkmm-3.0` included -std=c++11. But there are some applications (a minority?) that require e.g. -std=gnu++11 or -std=c++14. For those applications it's necessary to exclude -std=c++11 from pkg-config's output. Anyone having an idea how to achieve that? `pkg-config --cflags-only-I gtkmm-3.0` is probably not a good solution. It would remove more than just -std=c++11, e.g. -pthread from glib.
Hacking this via the pkg-config files feels unacceptable. I don't see any alternative to updating the packages that depend on *mm. Some disruption was expected. The build changes needed are minor - it's generally easy to add CXXFLAGS="--std=c++11" in packages without even patching the upstream build files. If this is unbearable to packagers then they can delay upgrading gtkmm (and friends) until C++11 (or C++14) is the default in g++. That will still cause some minor problems, for instance in applications whose source code uses C++11 keywords, but then that will be g++'s fault instead of ours.
*** Bug 756504 has been marked as a duplicate of this bug. ***
To give some perspective: After updating the MM stack in Debian I rebuilt all reverse dependencies. 88 from 109 failed to build. Adding -std=c++11 to libsigc++-2.0.pc (which is probably the central component by the MM stack and included everywhere) lead to 33 from 109 packages failing to build. A quick glance at the 33 packages shows packages, which e.g. don't use pkgconfg, say cmake, or are broken by othe API changes, mostly libsigc++-2.0 dropping headers Thats a huge churn
For anyone interested, the build logs are at https://people.debian.org/~biebl/mm-stack/ -> logs-sid is the current state in sid with an unmodified, up-to-date MM stack -> logs-glibmm is a rebuild with -std=c++11 added to glibmm2.4.pc -> logs-libsigc++ is a rebuild with -std=c++11 added to libsigc++2.0.pc
I've looked at all the 33 log files in https://people.debian.org/~biebl/mm-stack/logs-libsigc++/failed/ Summary ------- 10 packages don't use pkg-config 6 packages include sigc++/object.h 2 packages include sigc++/class_slot.h 1 package uses the deleted sigc::is_base_and_derived<> class 1 package overrides -std=c++11 by adding the -ansi compiler option 1 package uses pkg-config when a C file is compiled, and then -std=c++11 is illegal 5 packages contain code which is illegal in C++11, but legal in older C++ 3 packages (possibly more) contain code which has become ambiguous as a result of more functions and classes being available in C++11 Probably some packages contain more problems than those I've found. Comments to each log file ------------------------- arc-gui-clients_0.4.6-1.log Does not use pkg-config azr3-jack_1.2.3-2.log Call to ref() ambiguous because of sigc::ref() and std::ref() Other interesting problems barry_0.18.5-1.1.log Call to ref() ambiguous because of std::ref() and std::tr1::ref() cadabra_1.39-0.2.log sigc++/object.h: No such file or directory cyphesis-cpp_0.6.0-3.log 'constexpr' needed for in-class initialization of static data member dino_0.2.8-3.log -std=c++11 is overridden by -ansi eq10q_2.0~beta7.1~repack0-1.log Does not use pkg-config gip_1.7.0-1-3.log sigc++/class_slot.h: No such file or directory gparted_0.19.0-3.log sigc++/class_slot.h: No such file or directory granule_1.4.0-7-5.log sigc++/object.h: No such file or directory guitarix_0.32.1-1.log Does not use pkg-config jstest-gtk_0.1.1~git20140501-1.log unrecognised debug output level ' -O2 -fstack-protector-strong -Wformat -Werror=format-security' (The g++ command contains double quotes, which is probably wrong.) k3d_0.8.0.3-8.log Does not use pkg-config lifeograph_1.2.1-1.log Does not use pkg-config mangler_1.2.5-2.log narrowing conversion of '255' from 'int' to 'char' inside { } mysql-workbench_6.3.4+dfsg-1.log Does not use pkg-config ./configure tries to build several test programs using gtkmm without -std=c++11 open-vm-tools_2:9.10.2-2822639-3.log command line option '-std=c++11' is valid for C++/ObjC++ but not for C paco_2.0.9-3.log Does not use pkg-config passepartout_0.7.1-1.1.log sigc++/object.h: No such file or directory pcb2gcode_1.1.4-git20120902-1.log Use of shared_ptr ambiguous because of boost::shared_ptr and std::shared_ptr rawtherapee_4.2-2.log Does not use pkg-config repsnapper_2.3.2a5-1.log Call to isnan() ambiguous (don't know why) seq24_0.9.2-2.log return-statement with a value, in function returning 'void' void value not ignored as it ought to be (When std::bind is used in a sigc::slot) showq_0.4.1+git20090622+dfsg0-2.log Does not use pkg-config sigx_2.0.2-5.log expected identifier before 'static_assert' (A struct is named static_assert, not allowed in C++11) Uses the removed sigc::is_base_and_derived<> class sigc++-2.0/sigc++/adaptors/deduce_result_type.h:64:42: error: call of overloaded 'test()' is ambiguous sooperlooper_1.7.3~dfsg0-1.log sigc++/object.h: No such file or directory stardict_3.0.1-9.2.log narrowing conversion of '207' from 'int' to 'char' inside { } subtitleeditor_0.52.1-1.log Does not use pkg-config svxlink_14.08.1-1.log 'constexpr' needed for in-class initialization of static data member synfig_1.0-2.log Call to isnan() ambiguous (don't know why) synfigstudio_1.0-1.log sigc++/object.h: No such file or directory varconf_1.0.0-2.log some symbols or patterns disappeared in the symbols file (Don't know why this one failed) visualboyadvance_1.8.0.dfsg-2.log sigc++/object.h: No such file or directory
Thanks a lot Kjell for the detailed analysis. Looks like there is quite some work ahead to get that all sorted.
Michael, as I mentioned in comment #5, I think it's fine for you to just not use the latest libsigc++ for now. You can stick with libsigc++ 2.4.x. But many thanks for trying. The next g++ will use C++11 (actually, C++14) by default, solving many of these build issues. Most of the remaining build issues will then have nothing specifically to do with libsigc++. And in the meantime, some upstream developers will have released new versions to fix their builds, thanks to people such as yourself letting them know about the problems.
Closing for now because I don't think anyone still thinks we should be doing this via pkg-config. And soon gcc 6 will default to C++14 anyway.
Debian seem to have put -std=c++11 in the pkg-config file for its libsigc++ package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800399 That is very unwise and inconvenient for application developers, particularly as they now start to use C++14. As an upstream developer, I wish Debian would not do this. Michael, is this something that you can fix?
The alternative was to have 30+ packages instantly unbuildable, and have to patch each one of them to add -std=c++11. We added that to libsigc++'s cflags to avoid that, and only until the reverse dependencies got fixed. c++14 is the default in GCC 6.1, so we should be able to drop -std=c++11 as soon as that becomes the default compiler, without causing any build failures in reverse dependencies. Hopefully it won't be too long until that happens.
Or maybe packages have been fixed and dropping -std=c++11 from the cflags wouldn't cause too much breakage... a rebuild is probably required to check that.
No, the easiest alternative was just not to package that newer version of libsigc++, as I suggested. I don't think that anything whatsoever forced you to upgrade libsigc++. And if you did need to use the latest libsigc++, then adding --std=c++11 to the other packages would have been the correct thing to do, and therefore the easiest thing to do in the medium term. This was a hack that will cause more pain for you and for us. Doing it properly would have been a little tedious, but far from complicated.
Sure. However, I guess that whoever uploaded the newer version of libsigc++ (not me) didn't see this coming. So the hack (I acknowledge it's a hack) was temporarily added to prevent so many packages from becoming unbuildable. I think we can wait a few more days. GCC 6.1 is being released and we'll probably see a switch soon. Then we can drop this hack and put all this behind us.
yep, this was my fault. I wasn't aware of the implications when I uploaded 2.6. A more prominent warning (in the NEWS files) might have helped, but that's water under the bridge. I only remember one case where forcing -std=c++11 via libsigc++'s pc file caused an issue. So yeah, it's unfortunate, but it will sort itself out. Apologies for the inconvencience this might have caused.
Sidenote: The values contained in the "Cflags" variable, like "-std=c++11", will be added to the C_FLAGS by CMakes "pkg-config" module. gcc is happy tugging along, but clang will complain fatally: error: invalid argument '-std=c++11' not allowed with 'C/ObjC'