This question already has answers here:
How to suppress GCC warnings from library headers?
(10 answers)
Closed 7 years ago.
In the software project I'm working on, we use certain 3rd party libraries which, sadly, produce annoying gcc warnings.
We are striving to clean all code of warnings, and want to enable the treat-warnings-as-errors (-Werror) flag in GCC.
Is there a way to make these 3rd party generated warnings, which we cannot fix, to disappear?
Use -isystem
Example:
gcc -I./src/ -isystem /usr/include/boost/ -c file.c -o obj/file.o
With -isystem NO warning about boost :D
If you're using CMake, you can achieve this by adding SYSTEM to include_directories:
include_directories(SYSTEM "${LIB_DIR}/Include")
^^^^^^
I presume you are talking about the warnings coming from the 3rd party library headers.
The GCC specific solution would be to create another wrapper header file which has essentially the two lines:
#pragma GCC system_header
#include "real_3rd_party_header.h"
And use the wrapper instead of the original 3rd party header.
Check another SO response detailing the pragma. It essentially tells GCC that this (with recursively included files) is a system header, and no warning messages should be generated.
Otherwise, I'm not aware how one can disable warnings coming from the 3rd party code. Except by the brute force of course: in the build system configure the files to be built with warnings off.
http://www.artima.com/cppsource/codestandards.html
Example 1: A third-party header file.
A library header file that you cannot
change could contain a construct that
causes (probably benign) warnings.
Then wrap the file with your own
version that #includes the original
header and selectively turns off the
noisy warnings for that scope only,
and then #include your wrapper
throughout the rest of your project.
Related
I'm trying to run clang-tidy on a big project with a lot of files that include third party libraries:
#include "third_party/..."
And thus I receive a lot of errors corresponding to these third party libraries.
Adding NOLINT to each include is not an option since the project is large (and it seems that it doesn't work).
I tried to use -header-filter, but I still receive errors from third party libraries.
clang-tidy -header-filter='-third_party' "${SOURCE_FILES[#]}"
Is it possible to exclude third_party/* from checks?
You should flag these headers as system headers.
You can do this via
#pragma clang system_header
These headers will get ignored by clang-tidy and will produce no warnings.
I am working on a C++ cmake project. Apart from my own source code, my project uses a lot of third party libraries. So, I am using shared libraries (with .so extension) which are present in /usr/local/lib and for some the code is present in /usr/local/include. (like I am using eigen library which is present in /usr/local/include/eigen3/).
How can I make sure that the Address Sanitizer only checks my source code and not any standard or third party libraries ??
PS : Currently, I am using Address Sanitizer like below :
ADD_COMPILE_OPTIONS(-O0 -g -Wall -fsanitize=address -fno-omit-frame-pointer)
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address")
And I am using gcc with version :
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
AddressSanitizer works by inserting code during the compilation (with the -fsanitize=address flag). So most code in third party libraries your code links to will be unaffected and not checked by AddressSanitizer, as they are already built into shared library files. If 3rd party calls standard function (memset, etc.), it'll still be checked.
Code in header files and header-only libraries such as Eigen are a special case, as all Eigen code gets directly inserted into your source files (through includes) and thus is also compiled with -fsanitize=address.
As the compiler doesn't differentiate between your code and included 3rd party code, there is no way to disable sanitizers for header-only 3rd party code.
In practice this does not usually cause any issues though. When using clang, you can create a sanitize-blacklist file to hide unwanted false positives (that you cannot fix upstream). Unfortunately gcc does not yet support blacklists.
Several static analysis tools designed for C/C++ exist, but they are not particularly useful for testing CUDA sources.
Since clang version 6 is able to compile CUDA, I wanted to check what are my options with using clang-tidy, which does not seem to have option for switching architectures.
Is there a way to make it work? For example compile time switch for turning on CUDA parser, extension in form of custom check, or is it maybe planned feature?
One of the problem with the clang-based tools is that they are not parsing the files in exactly the same way as clang does.
The first problem is that unlike C/C++ compilation, CUDA compilation compiles the source multiple times. By default clang creates multiple compilation jobs when you give it a CUDA file and that trips many tools that expect only one compilation. In order to work that around you need to pass --cuda-host-only option to clang-tidy.
You may also need to pass --cuda-path=/path/to/your/CUDA/install/root so clang can find CUDA headers.
Another problem you may run into would be related to include paths. Clang-derived tools do not have the same default include paths that clang itself uses and that occasionally causes weird problems. At the very least clang-tidy needs to find __clang_cuda_runtime_wrapper.h which is installed along with clang. If you run clang-tidy your-file.c -- -v it will print clang's arguments and include search paths it uses. Compare that to what clang -x c /dev/null -fsyntax-only -vprints. You may need to give clang-tidy extra include paths to match those used by clang itself. Note that you should not explicitly add the path to the CUDA includes here. It will be added in the right place automatically by --cuda-path=....
Once you have it all in place, clang-tidy should work on CUDA files.
Something like this:
clang-tidy your-file.cu -- --cuda-host-only --cuda-path=... -isystem /clang/includes -isystem /extra/system/includes
There are two ways, as far as I can tell, to ignore warnings for external libraries.
First way is to use #pragma:
#pragma gcc diagnostic ignored "-Wunused-parameter"
Second way is to add -isystem/path/to/system/lib to the compiler flags. This labels that particular include path as an external include path, and so the compiler will not emit warnings stemming from those includes.
I have a large project with many compilation targets, some of which use particular third party libraries which cause problems for my compiler. For reasons I cannot use the #pragma option.
But if I use the -isystem as a blanket compiler flag for all build targets, then I will unfortunately include /path/to/system/lib for every other build target, even those which do not use that system library. This means other targets will search through those external libraries, which is not desirable.
Is there a compiler option, similar to -isystem which can be added in a blanket way, which does not add to the search path, but only excludes warnings if the path happens to already be included in the search path?
I have a large project with many compilation targets, some of which use particular third party libraries which cause problems for my compiler. For reasons I cannot use the #pragma option.
Can you elaborate on this? Why is a wrapper header with #pragma GCC diagnostic not an option? That is, something like this:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"
#include </path/to/real/include.h>
#pragma GCC diagnostic pop
(Or if you want to get fancy, use #include_next.) You would apply this only when crossing subsystem boundaries; the subsystem itself would be compiled with -Wunused-parameter.
I don't see anything in the GCC/libcpp sources which would allow one to reset the system header flag without adding a new system header. In any case, this looks to me like something which could be reasonably addressed within the build system.
I am involved with a software project written in Qt and built with qmake and gcc on Linux. We have to link to a third-party library that is of fairly low quality and spews tons of warnings. I would like to use -W -Wall on our source code, but pass -w to the nasty third-party library to keep the console free of noise and clutter so we can focus on our code quality.
In qmake, is there a way to conditionally add CFLAGS/CXXFLAGS to certain files and libraries?
Jonathan, I think the problem is where your source files are including header files from 3rd party libraries, and you want to switch off the warnings for the latter.
Kevin, i think you can use pragmas to control warnings : gcc diagnostic pragmas
You could add these before and after any #includes for 3rd party libs.
What if you include your library using -isystem.
In the project file e.g.:
QMAKE_CXXFLAGS += -isystem /usr/local/boost_1_44_0
Normally, you'd build the third-party library in a separate directory from your own code, so you would have a different makefile for it, so you could put a different set of flags for that compilation.
If you've mixed the third-party library code with your own code, you have set yourself up for a maintenance nightmare.
Kevin,
qmake CONFIG+=debug QMAKE_CXXFLAGS_WARN_ON=-w QMAKE_CFLAGS_WARN_ON=-w
should do
(use CONFIG+=release if you wish...)
As Martin wrote adding the include directory via
QMAKE_CXXFLAGS += -isystem ...
suppresses warnings just in the respective headers. No need to disable warnings for any source files of your project (or even project-wide) or mess with #pragmas or wrappers files.
Note that if you're using QtCreator you'll still (i.e. additionally) want add the directory to INCLUDEPATH so the indexer picks up the headers.