165

I have a project that uses log4cxx, boost, etc. libraries whose headers generate lots of (repetitive) warnings. Is there a way to suppress warnings from library includes (i.e. #include <some-header.h>) or includes from certain paths? I'd like to use -Wall and/or -Wextra as usual on project code without relevant info being obscured. I currently use grep on make output but I'd like something better.

AdSR
  • 2,097
  • 3
  • 15
  • 9

10 Answers10

148

For those using CMake, you can modify your include_directories directives to include the symbol SYSTEM which suppresses warnings against such headers.

include_directories(SYSTEM "${LIB_DIR}/Include")
                    ^^^^^^
Drew Noakes
  • 300,895
  • 165
  • 679
  • 742
  • 1
    What if the library provides a `${LIBFOO_USE_FILE}` variable that is to be used with CMake's [include()](https://cmake.org/cmake/help/latest/command/include.html) command? – waldyrious Oct 07 '16 at 10:46
  • 2
    This seems to be almost the solution to my problem. I have 1.) a binary target, which depends on 2.) a header only target written by myself, which depends on 3.) some external libraries. I have no idea how to only get warnings for 1&2. You have any ideas? – knedlsepp Oct 11 '16 at 11:53
  • 2
    Doesn't seem to work. I tried this with a project that uses `easylogging++` and I get the same huge amount of warnings from the `easylogging++.h` even though the folder where it resides has been included with `SYSTEM` option. – rbaleksandar Mar 02 '18 at 13:48
  • Thanks SO MUCH for this. It has saved me from pages and pages of warnings. – Svalorzen Mar 21 '18 at 12:59
  • I have used this strategy consistently for some time now but it breaks the compilation when used with the new gcc versions (at least > 6.0). The problem is that `-isystem` doesn't play well with the #include_next directive that is used for example that is now used in (https://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors) – bergercookie May 21 '18 at 09:23
  • 1
    Same comment as for the accepted answer: this is bad practice for me. – Raffi Sep 21 '18 at 06:55
146

You may try to include library headers using -isystem instead of -I. This will make them "system headers" and GCC won't report warnings for them.

Joren
  • 14,472
  • 3
  • 50
  • 54
Phi
  • 1,492
  • 1
  • 9
  • 2
  • 11
    If you're trying to do this in XCode then stick -isystem path into your "other C++ flags" in the "custom compiler flags" in your target build settings. – Matt Parkins Dec 11 '13 at 12:08
  • 5
    One potential downside is that on some platforms, g++ will automatically wrap any system headers in `extern "C"`, leading to odd errors about C linkage if you `#include` a C++ header in an `-isystem` path. – Tavian Barnes Feb 23 '16 at 14:57
  • 1
    +1 helped me to solve problems with annoying boost warnings http://stackoverflow.com/questions/35704753/warnings-from-boost – mrgloom Mar 01 '16 at 13:35
  • 3
    Why does this have so many more votes than the OP's own answer that said exactly the same thing 1.5 hours earlier? – underscore_d Jul 21 '16 at 20:11
  • 1
    For Xcode: What if there was no folder path in "Other C++ flags" in my target build settings? Could someone elaborate on this solutions? – Ossir Oct 13 '16 at 09:39
  • How to do this in eclipse ? – Arun Pal Nov 13 '17 at 12:55
  • You should be really careful with this, and I consider this as a bad practice. This `-isystem` is meant for system libraries that are de fact standard compliant, it is not meant for silencing warnings in some third party library. Those warnings should just be fixed. – Raffi Sep 21 '18 at 06:54
  • 1
    @Raffi And how do you fix warnings in a third party library that chose to suppress those warnings? – rozina Oct 19 '18 at 12:53
  • @rozina many ways: you include them with 2 guards that suppress and enable the warnings, you post pull requests upstream. – Raffi Oct 20 '18 at 13:05
  • Thanks to Tavian Barnes, that was exactly the issue I had and I could not understand. g++ was failing with qt-related projects, shouting at me how stdlib.h can not be found even though it was there at /usr/include/ (but a symlink to where my glibc resides). – shevy Aug 31 '19 at 11:14
66

You can use pragmas. For example:

// save diagnostic state
#pragma GCC diagnostic push 

// turn off the specific warning. Can also use "-Wall"
#pragma GCC diagnostic ignored "-Wunused-but-set-variable"

#include <boost/uuid/uuid.hpp>
#include <boost/uuid/uuid_generators.hpp>
#include <boost/uuid/uuid_io.hpp>
#include <boost/lexical_cast.hpp>

// turn the warnings back on
#pragma GCC diagnostic pop
wheybags
  • 627
  • 4
  • 15
andrewrjones
  • 1,801
  • 21
  • 25
  • 3
    Only available with GCC >= 4.6 – Caduchon May 19 '15 at 12:14
  • 1
    i'm loving the ability of push/pop pragmas. i remember something like for java available years ago and being frustrated/jealous for C/C++. i love that this is available in `gcc` – Trevor Boyd Smith Mar 30 '18 at 16:06
  • 1
    @TrevorBoydSmith MS `cl` has had the ability for years too... At times `gcc` is a bit slow to adapted. – Alexis Wilke May 16 '20 at 00:16
  • 1
    It seems you can only disable warnings one by one, i.e. `-Wall` does not work. See [related question](https://stackoverflow.com/questions/32049296/how-to-disable-all-warnings-using-pragma-directives-in-gcc) – luator Jan 28 '21 at 13:15
35

I found the trick. For library includes, instead of -Idir use -isystem dir in the makefile. GCC then treats boost etc. as system includes and ignores any warnings from them.

AdSR
  • 2,097
  • 3
  • 15
  • 9
  • 1
    Note that if you use precompiled header you need to add the flag when you compile both the header and the code. – user202729 Nov 13 '19 at 07:51
9

#pragma are instructions to the compiler. you can set something before the #include and disable it after.

You can also do it at the command line.

Another GCC page specifically on disabling warnings.

I would go for the option of using #pragma's within the source code, and then providing a sound reason (as a comment) of why you are disabling the warnings. This would mean reasoning about the headers files.

GCC approaches this by classifying the warning types. You can classify them to be warnings or to be ignored. The previously linked articles will show you which warnings are may be disabled.

Note: you can also massage the source code to prevent certain warnings by using attributes; however, this bind you quite closely to GCC.

Note2: GCC also uses the pop/push interface as used in microsoft's compiler -- Microsoft disables warnings through this interface. I suggest you investigate this further , as I do not know if it is even possible.

Hassan Syed
  • 20,075
  • 11
  • 87
  • 171
  • 1
    I considered pragmas but if I suppress a warning before including a header, how do I set it back to the *previous state* after #include? I want to see all warnings for the project code (helped me already a few times) but have control from command line. – AdSR Dec 08 '09 at 14:03
5

Putting the following

#pragma GCC system_header

will turn off GCC warnings for all following code in this file.

Evgenii
  • 36,389
  • 27
  • 134
  • 170
4

You can try using precompiled headers. Warnings won't go away but at least the won't show up in your main compilation.

Pablo Santa Cruz
  • 176,835
  • 32
  • 241
  • 292
  • 1
    This might actually be a good idea. Third-party includes don't change every day. – AdSR Dec 08 '09 at 14:04
  • Exactly. Although I haven't used them that much in Linux, they work pretty well on Visual Studio. – Pablo Santa Cruz Dec 08 '09 at 15:07
  • No, they will still show up in the compilation unless you use some other way to suppress them (such as `-isystem`, but remember to use it both in compiling the header and in the code) – user202729 Nov 13 '19 at 07:50
2

If you need to explicitly override a system header then you're restricted to pragmas. You can verify which includes you're using via make depend output.

Also see diagnostic push-pop for gcc >= 4.6

Community
  • 1
  • 1
supaflav
  • 99
  • 4
0

Another way to do it is, in the makefile, to tell the compiler to ignore warnings for the specific folder:

$(BUILD_DIR)/libs/%.c.o: CFLAGS += -w
DianaNowa
  • 21
  • 7
  • This suppresses all warnings, not just those in the headers of external libraries, which very likely isn't desired. – user686249 Feb 03 '21 at 10:59
-9

There must be reasons for those warnings. These will either be caused by errors in your code that uses the library, or by errors in the library code itself. In the first case, fix your code. In the second case, either stop using the library or if it is FOSS code, fix it.

  • +1 for good advice :D but he is asking how to do something specific :D – Hassan Syed Dec 08 '09 at 13:50
  • 6
    Some warnings are impossible or very hard to fix, especially in 3rd-party code, *especially* in such metaprogramming-rich code as Boost's. – ulidtko Aug 04 '11 at 16:38
  • 3
    Worse the one that is bugging me is *"declaration of 'c' shadows a member of 'this' [-Werror=shadow]"* deep, deep in some boost header. That is certainly not a problem, but it and similar issues are spewing output and making it hard for me to find instances a real shadowing in our code-base. – dmckee --- ex-moderator kitten Nov 16 '11 at 18:36