Eigen & GCC 5 : class std::binder2nd is deprecated - gcc

I just restarted working on a project which has been on hold for a few months. Last time I compiled it it was working just fine, without any error nor warning.
Yet when I tried to compile it earlier today I got this warning
attention : ‘template<class _Operation> class std::binder2nd’ is deprecated [-Wdeprecated-declarations]
This warning literally appears hundreds of time when including Eigen/Geometry, which I use all over my project
In file included from [...]/include/Eigen/src/Core/ArrayBase.h:109:0,
from [...]/include/Eigen/Core:350,
from [...]/include/Eigen/Geometry:4,
from [...]/include/[myproject]/types.hh:8,
from [...]/include/[myproject]/voronoi.hh:8
Since then I haven't updated Eigen (is used 3.2.4 which is still the last update today).
However, since last time I compiled it, GCC has been updated to 5.1.0 (I'm using archlinux)
Question:
Is there an issue with gcc 5.1.0 telling me std::binder2nd is deprecated
Should Eigen be updated ?
How can I silent those specific warning without loosing the verbosity of my build ?
ANSWER
I appreas that std::bind2nd is really deprecated and that a commit has been done to solve that in Eigen. This commit is however not yet merged with the master branch :/ (and doesn't solve the issue as some std::bind2nd are still present in Eigen's code)
Bottom line is: Eigen's last stable version is deprecated

Is there an issue with gcc 5.1.0 telling me std::binder2nd is deprecated
No, the C++ standard says it's deprecated in C++11, so if you compile in C++11 mode then it is supposed to be deprecated.
Should Eigen be updated ?
Yes. if it wants to be C++17 compatible, as std::bind2nd doesn't exist post-C++14 at all.
How can I silent those specific warning without loosing the verbosity of my build ?
Suppress the warning. Either compile with -Wno-deprecated-declarations on the command-line or do it in the source when including the Eigen headers:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#include <eigen/whatever.h>
#pragma GCC diagnostic pop
Or, as the other answer says, tell GCC to treat the Eigen headers as system headers, which happens automatically if they are in /usr/include, or are included with -isystem, or are included from another header that does:
#pragma GCC system_header
#include <eigen/whatever.h>

How can I silent those specific warning without loosing the verbosity ?
Edit the CMakeLists.txt file. Add this line somewhere after CMAKE_CXX_FLAGS is set.
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-deprecated-declarations")
Previous answer mentioned adding this to #pragma or to command line. I am biased against #pragma because I find it hard later on to remember where I put it. So as general practice, I try to avoid #pragma. Adding to command line means you have to remember to type this everytime you recompile.

Instead of using the -I flag to include files use -isystem to include Eigen headers:
g++-5 -isystem/usr/include/eigen3 source_file_here.cpp
This flag is intended for system headers that don't conform to C standards but are considered false positives when warnings are generated. Eigen headers are used much like system headers and thus for most users the warnings are not helpful but merely an annoying false positive.
Credit goes to Ilya Popov's comment in the original question.

Related

Disable compiler warnings with pragma GCC diagnostic in LTO builds

I'm having troubles disabling GCC warnings with LTO-enabled builds:
Some warnings (-Wstrict-overflow, -Wmaybe-uninitialized, ...) are
specified on the command line using the -W option switch for compiling
all files within a project. However, I'd like to disable them just on some specific code locations.
Without LTO mode, "#pragma GCC diagnostic ignored" (along with #pragma
push & pop) works smoothly. However, those pragma declarations seem to be ignored when the compiler is invoked back at link stage (LTO build).
Is there a workaround, or a better way to disable specific warning in
specific code locations?
Many thanks in advance :)

How to suppress GCC compiler warning: inline variables are only available with -std=c++1z or -std=gnu++1z

I am using an inline global variable which works well for the purpose of it.
class MyClass {
public:
void Func() {
}
}
inline MyClass myClass; // global inline variable
Above works well for my purpose but I get a warning when my code compiles on gcc with compiler below C++17. Following is the warning
warning: inline variables are only available with -std=c++1z or
-std=gnu++1z
Question:
How can I suppress the warning on gcc?
I tried to suppress the warning by using a #pragma like below
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wc++17-extensions"
inline MyClass myClass;
#pragma GCC diagnostic pop
Above #pragma technique works on clang, but looks like GCC to not understand the #pragma? I just want to brute force suppress the warning on GCC. How can I do that?
Looks like gcc warning options list does not even mention about this?
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
I am using gcc (GCC) 7.3.0
To understand why you cannot suppress this warning, look at what happens if the code is compiled with a compiler that does not support inline variables. (Inline variable support started with gcc 7.) Older versions of gcc process your code and spit out error: 'myClass' declared as an 'inline' variable. Not a warning, but an unsuppressible error. Hard stop; object code not produced.
Newer versions of gcc are able to be more understanding and helpful, but at the same time they have an obligation to maintain some degree of compatibility with older compilers. These newer compilers can recognize this C++17 feature, and it's been determined that ignoring "inline" downgrades the error to a warning (compilation does not necessarily need to stop). Furthermore, the message was given information about how to resolve this situation (assuming the code is correct). At the same time, this warning is still essentially the error produced by older versions of gcc, just given a makeover to make it more user-friendly. It cannot be suppressed any more than the old error could. Your choices are to write valid pre-17 code or to enable C++17 features.

Deprecation notices building using GTKMM with C++11

I'm trying to use GTKMM with a project which makes use of C++11 features.
The problem is that apparently C++11 deprecated some parts of the language, which GTKMM seems to be using.
Is there any way to get rid of those messages while keeping the useful compiler warnings for my code?
The compiler is GCC 5.2 on Linux. These are the notices I'm talking about:
In file included from /usr/include/glibmm-2.4/glibmm/wrap.h:23:0,
from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:26,
from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:23,
from /usr/include/glibmm-2.4/glibmm.h:91,
from /usr/include/gtkmm-3.0/gtkmm.h:87,
from test.cpp:1:
/usr/include/glibmm-2.4/glibmm/objectbase.h:215:13: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations]
static std::auto_ptr<Threads::Mutex> extra_object_base_data_mutex;
^
In file included from /usr/include/c++/5.2.0/memory:81:0,
from /usr/include/glibmm-2.4/glibmm/objectbase.h:32,
from /usr/include/glibmm-2.4/glibmm/wrap.h:23,
from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:26,
from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:23,
from /usr/include/glibmm-2.4/glibmm.h:91,
from /usr/include/gtkmm-3.0/gtkmm.h:87,
from test.cpp:1:
/usr/include/c++/5.2.0/bits/unique_ptr.h:49:28: note: declared here template<typename> class auto_ptr;
In case its something wrong with the compiler parameters, here's the CMakeLists ( was reused from an OpenCV project, please tell in case there is something wrong in the file):
cmake_minimum_required(VERSION 3.3.0 FATAL_ERROR)
list( APPEND CMAKE_CXX_FLAGS "-std=c++0x ${CMAKE_CXX_FLAGS} -g -ftest-coverage -fprofile-arcs -libs")
project( interface )
find_package(PkgConfig REQUIRED)
pkg_check_modules(GTKMM REQUIRED gtkmm-3.0)
include_directories(${GTKMM_INCLUDE_DIRS})
link_directories(${GTKMM_LIBRARY_DIRS})
add_definitions(${GTKMM_CFLAGS_OTHER})
add_executable( interface test.cpp )
target_link_libraries(interface ${GTKMM_LIBRARIES})
We fixed this in glibmm fairly recently:
https://bugzilla.gnome.org/show_bug.cgi?id=748630#c11
So the best way to fix it for your build is to update your glibmm and gtkmm versions, when you can.
Just a dirty hack (because probably the usage of auto_ptr inside GTKMM is questionable so you want to report a bug to GTKMM); you might use some diagnostic pragmas and replace #include <gtkmm.h> with
//untested code
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#include <gtkmm.h>
#pragma GCC diagnostic warning "-Wdeprecated-declarations"
But auto_ptr is indeed deprecated in C++11 and I am not sure it mixes well with your C++11 standard library.
(Perhaps using Qt5 instead of GtkMM might be reasonable, since GtkMM might not be maintained for long, however it seems to know the issue; otherwise hope and perhaps contribute to improving GtkMM).
You probably should also use valgrind in your tests

Purpose of __USE_XOPEN2K8 and how to set it?

I'm trying to compile the gtk stack (the last gtk2 version, 2.24), and I am getting a bunch of errors that seem related. Namely, the __locale_t can't be found from string.h and time.h, and LC_ALL_MASK can't be found either (should be in locale.h).
I found that all of these problems are related to __USE_XOPEN2K8 not being #defined. What is __USE_XOPEN2K8 for, and how can I set it propertly?
For example, do I have to pass a flag to ./configure for glib, gtk, ... or do I have to change something already while building gcc or glibc̲? I'd rather not just sprinkle #define __USE_XOPEN2K8 in to my sources without knowing what it does. Note I'm using gcc-4.6.3 and glibc-2.16.0 which are installed in a nonstandard prefix, as I'm trying to get the gtk libraries to work on an older CentOS (5.8) that only includes older versions.
Also note the missing __locale_t is mentioned in several places, e.g. this bugreport. I could just add #include <xlocale.h> in some files, but it seems the proper solution would be to get __USE_XOPEN2K8 to be set.
Edit: I've found this thread describing the problem. Apparently, headers of the host system get "fixincluded" into the headers of the new compiler. The linked post suggests to edit features.h. Does anyone know if I have to recompile gcc / glibc afterwards (and how to get it to pick up the new features.h, rather than overwriting it)?
When __USE_GNU is defined, __USE_XOPEN2K8 is always defined as well, unless you
are explicitly defining or undefining these macros, which you must not do.
Use _GNU_SOURCE, _XOPEN_SOURCE {500,600,700,...} etc. macros before including
the first header instead. This is the recommended way to select the GNU feature set in glibc headers, together with defining it on the command line (-D_GNU_SOURCE).
Alternatively, you can try specifying GNU extension usage to gcc through the -std command line switch (gnu89, gnu99, and so forth).
On CentOS7 with gcc 4.6 we had to use -D_XOPEN_SOURCE=700 -D__USE_XOPEN2K8
The glibc __USE_* macros are internal macros used to implement feature selection. The supported way to set them is to define feature test macros such as -D_GNU_SOURCE:
Feature Test Macros
These macros are needed because glibc supports many standards and GNU extensions, and these features are in conflict with each other, mostly due to the lack of namespaces in C. For example, C and POSIX allow you to define a global variable called secure_getenv (because the identifier is not reserved or otherwise used by those standards), but such a program will not work if you compile with _GNUS_SOURCE and include <stdlib.h> because glibc provides a function called secure_getenv.
<xlocale.h> is an internal glibc header (a comment within the header file says so) and will no longer be available in glibc 2.26.
As I know when we use the complier, it's behavior depends on some ENV macros, which saved in feature.h. So you can configure your complier by modifyinfg it.
Fisrt,you need use g++ -E youfile > log, to see which feature.h file your complier use, and then use g++ -E -dM /path/to/feature.h>log, to find the __USE_XOPEN2K8, if you can't find it. Add #define __USE_XOPEN2K8 1 at the end of the file.You know may be you have do some configure wrong when you install you complier.

Removing Flag in GCC using Pragma

I want to remove a compiler flag for a praticular file in my project. How to do this using #pragma?
Sorry that this is late, but I just ran into the same issue on my project.
I couldn't find a #pragma to modify the list of compiler flags, but I could use GNU Make's ability to modify make variables on a per-target basis.
One of my files was taking forever to compile with -fvar-tracking-assignments (which was added to -O2 a few releases back). I was looking for a way to turn that off for one file; after looking (in vain) for an appropriate pragma, I simply added this line to my makefile to modify CXXFLAGS when compiling and linking those specific files:
ObtuseObj.o ObtuseObjTest.o ObtuseObjTest : CXXFLAGS += -fno-var-tracking-assignments
Hopefully this will be helpful to others!
Only flags that control warnings can be overridden using #pragma, see the diagnostic pragmas documentation page.
For instance, you could do:
#pragma GCC diagnostic ignored "-Wformat"
To make GCC ignore the warnings generated by mismatched formatting strings.
I'm not sure if gcc has such pragmas. I can't find any on the gcc page for pragmas.
If you are asking a question related to gcc next time, tag it under gcc as well. I would tag it but I can't. Tagging under gcc would get you many more responses.

Resources