I am on Ubuntu 16.04, GCC 5.4.
According to here one can disable warnings from external headers by treating them as system headers. However, when I am using VTK I came across a warning that I am unable to disable. Below is the minimum code to reproduce it
#include "vtkVersion.h"
int main(){
return 0;
}
Compile it with g++ main.cpp -isystem /usr/include/vtk-5.10/ return warning message
In file included from /usr/include/c++/5/backward/strstream:50:0,
from /usr/include/vtk-5.10/vtkIOStream.h:108,
from /usr/include/vtk-5.10/vtkSystemIncludes.h:40,
from /usr/include/vtk-5.10/vtkIndent.h:24,
from /usr/include/vtk-5.10/vtkObjectBase.h:43,
from /usr/include/vtk-5.10/vtkObject.h:41,
from /usr/include/vtk-5.10/vtkVersion.h:29,
from Example.cpp:3:
/usr/include/c++/5/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
#warning \
^
If VTK is not installed you can simply install it with sudo apt-get install libvtk5-dev
Why does the warnings appeared? In my code I have very strict compiler flags and I treat warnings as errors. However, not all external libraries are coded with such strict compiler flags, I am able to get away with including the external headers with the -isystem flag but VTK is giving me problems. My ugly workaround is adding -Wno-deprecated in my own compiler flags to get pass it but obviously this is not the right way to do it. What's the best way to solve this?
Related
I was trying to include the GMP library, which was simply the code below(I did nothing else):
#include <gmpxx.h>
However, when I tried to compile the code, the following error from g++ compiler occured:
myCode.cpp:3:10: fatal error: gmpxx.h: No such file or directory
#include <gmpxx.h>
^~~~~~~~~~~~~~~~~~~~~~
I have tried everything I searched online, putting the GMP lib here and there, adding INFINITE includepaths in c_cpp_properties.json, still, it keeps showing the message, although, I can find the file through "Go to Definition" option.
Is there any known solution to this?
It's not enough to configure VS Code includes, you need to pass those options to the compiler as well.
You don't mention your platform at all, so I'm going to use an example from my personal machine, a Macbook Pro with the fmt library.
When compiling with the fmt library, I have to provide three more options to the compiler.
-I/usr/local/include // Tells the compiler where to look for extra includes
-L/usr/local/lib // Tells the compiler where to look for extra libraries
-lfmt // fmt-specific command to use fmt library
So the full command ends up looking like this:
g++ -Wall -std=c++17 -I/user/local/include -L/usr/local/lib -lfmt main.cpp
I need all three options because fmt is installed in a non-standard location that the compiler doesn't check by default. According to the documentation, you can get away with just -lgmp and -lgmpxx if you installed the library in a standard location (happens by default with *nix and a package manager, I imagine).
If you use build tasks in VS Code, this can be set up and automated for you.
For both Clang and GCC, the -isystem flag adds a "system" include path, which causes the compiler not to emit warnings related to code found in those headers.
However, running clang-check on my code, I see the following warning:
In file included from <myfile>.cpp:1:
In file included from <Qt-path>/gcc_64/include/QtCore/QCoreApplication:1:
In file included from <Qt-path>/gcc_64/include/QtCore/qcoreapplication.h:40:
<Qt-path>/gcc_64/include/QtCore/qobject.h:235:16: warning: Potential memory leak
return connectImpl(sender, reinterpret_cast<void **>(&signal),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
...so it would appear that clang-check does not treat -isystem include paths differently from -I include paths. Am I misusing the tool or misinterpreting the output (i.e., is this actually a potential error in my code)? Is there another way to explicitly ignore errors from Qt headers when running clang-check?
This is because you also have to include the "QtCore" directory via-"isystem", in addition to just the base Qt include directory. This is because Clang finds a more specific include (QT -Is the modules as well) and uses that. See the Clang Manual for -isystem information on how the includes work.
Effectively you want to do the following:
contains(QT,"core") {
QMAKE_CXXFLAGS *= $$join(QMAKE_INCDIR_QT, " -isystem", "-isystem", "/QtCore")
}
And repeat this for all standard Qt modules (Designer, Gui, Help, Network, etc).
I had this problem and arrived at this question via search engine. So for anybody else like me; the answer is to use the -extra-arg twice!
For example
./MyTool -extra-arg="-isystem" -extra-arg="my/system/include/path" myfile.cpp
And you don't get all those warnings.
I'm trying to get emscripten to work on OS X 10.8, see this post for some related issues there. Apparently the clang++ version shipped with Xcode is too old, so I got a recent clang 3.7.0 using MacPorts. I even told CMake to use that compiler (passing -DCMAKE_CXX_COMPILER=clang++-mp-3.7 on the command line), but it still fails:
[ 33%] Building CXX object CMakeFiles/optimizer.dir/parser.cpp.o
/opt/local/bin/clang++-mp-3.7 -std=c++11 -fno-exceptions -fno-rtti -O3 -DNDEBUG
-o CMakeFiles/optimizer.dir/parser.cpp.o
-c …/emsdk/emscripten/master/tools/optimizer/parser.cpp
In file included from …/emsdk/emscripten/master/tools/optimizer/parser.cpp:2:
In file included from …/emsdk/emscripten/master/tools/optimizer/parser.h:12:
…/emsdk/emscripten/master/tools/optimizer/istring.h:3:10: fatal error:
'unordered_set' file not found
#include <unordered_set>
^
1 error generated.
I can reproduce that issue by launching the compiler from the command line. In parallel build mode, sometimes it's instead complaining about <cstdint> for optimizer.cpp instead. Both these headers exist in /opt/local/libexec/llvm-3.7/include/c++/v1/.
What's the canonical way to use the macports-installed version of clang++ including its headers? Do I have to use -I and work out the full path, or is there something shorter?
Can I safely do so without also switching the runtime library to the one shipped with MacPorts' clang? If not, can I somehow encode the full path of the runtime library into the created binary, either for that single library or using the -rpath argument to ld or some equivalent alternative?
Update: I get unresolved symbols when I try to link stuff after specifying the include directory manually, and I don't know how to solve that. The libcxx package from MacPorts is empty except for a readme file.
I've solved the original problem by adding CXXFLAGS=--stdlib=libc++ to the environment. Then even the system version of clang will do everything I need. That flag works magic for MacPorts' version of clang as well: specifying that I get a successful build, and I can even verify (using the -E compiler switch) that it's using the headers I mentioned before. I'm still not certain whether there is anything to ensure that the headers match the system's version of libc++, though.
I have a c++ application (built under linux with g++ 4.8.3, boost 1.54) that spouts a lot of warnings about boost. Warnings include:
/usr/local/include/boost/math/constants/constants.hpp:314:3: warning: non-standard suffix on floating constant [-Wpedantic]
BOOST_DEFINE_MATH_CONSTANT(rayleigh_skewness, 6.311106578189371381918993515442277798e-01, "6.31110657818937138191899351544227779844042203134719497658094585692926819617473725459905027032537306794400047264e-01")
/usr/local/include/boost/concept/detail/general.hpp:71:20: warning: typedef 'boost_concept_check228' locally defined but not used [-Wunused-local-typedefs]
BOOST_PP_CAT(boost_concept_check,__LINE__)
...
There are so many different ones . It looks like from here that you can suppress particular typedef warnings: https://svn.boost.org/trac/boost/ticket/7242
But I would like to be able to suppress all of these warnings. Any suggestions?
As the commenter T.C. suggests, warnings are suppressed for system headers in gcc. There are (at least) two ways of adding additional system include paths to your gcc build:
-isystem command line option, and
*_INCLUDE_PATH environment variables (where '*' is C, CPLUS, or OBJC).
These mechanisms also work for clang.
I'm trying to compile introduce the -Werror flag in an existing codebase. One of the issues I'm encountering is that at some places #warning is used to display informational messages. These should not be treated as an error.
One solution would be to use #pragma message instead, but this does not seem to be supported by older versions of gcc. (Our build servers use gcc 4.1.2).
Can anyone help me fix this?
In gcc-4.6 and above, you can use -Wno-error=cpp. In at least the clang released with Lion and later, you can use -Wno-error=#warnings. But since your build servers use an ancient gcc, you're probably out of luck there.
In general, pass -fdiagnostics-show-option to have warnings show output like:
test.cc:1:2: warning: #warning hello [-Wcpp]
which tells you a warning flag that controls the warning. In gcc >=4.6 and clang, this is the default, so knowing to pass it may not be too useful anymore.
Locally disable effect of -Werror for #warning as follows:
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wcpp"
#warning Informative message: everything is nice and good!!!
#pragma GCC diagnostic pop
The benefit with this approach is that you can still induce error with #warning elsewhere in the code.