As stated by gcc's guide[1], GCC should suppress warnings (others than #warning ones) for system headers files. Unfortunately, at least 4.0.1 doesn't respect this. Trying to merge herdstat-1.1.1_p3 (which is built with -Werror) with -Wformat=2 in CFLAGS throws an error in c++locale.h file for a non-literal format string, that obviously can't be fixed from herdstat side. Seems like gcc doesn't know that its libstdc++ directory is a system directory (and same for Qt and KDE that throws a lot of warnings, btw). [1] http://gcc.gnu.org/onlinedocs/gcc-4.0.1/cpp/System-Headers.html#System-Headers
Works for me with gcc-4.0.2-r1. Reopen if this is still a problem.
i think this is PR21951 which was fixed in gcc-4.0.2
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../include -D__TRACE_AND_STATS_ -D__DOUBLE_PRECISION_ -D_REENTRANT -DNOCONTROLS -fexceptions -Wall -Werror -D_OBSS_ -Wall -Wno-char-subscripts -Woverloaded-virtual -Wno-unknown-pragmas -Wno-deprecated -Wformat=2 -march=athlon64 -Os -fomit-frame-pointer -ftracer -pipe -ftree-vectorize -Wformat=2 -DMPEG4IP -I/usr/include/SDL -D_REENTRANT -MT tools_sadct_sadct.lo -MD -MP -MF .deps/tools_sadct_sadct.Tpo -c tools_sadct_sadct.cpp -fPIC -DPIC -o .libs/tools_sadct_sadct.o cc1plus: warnings being treated as errors /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4/x86_64-pc-linux-gnu/bits/c++locale.h: In function 'int std::__convert_from_v(char*, int, const char*, _Tv, __locale_struct* const&, int) [with _Tv = double]': /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4/bits/locale_facets.tcc:1065: instantiated from '_OutIter std::num_put<_CharT, _OutIter>::_M_insert_float(_OutIter, std::ios_base&, _CharT, char, _ValueT) const [with _ValueT = double, _CharT = char, _OutIter = std::ostreambuf_iterator<char, std::char_traits<char> >]' /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4/bits/locale_facets.tcc:1225: instantiated from '_OutIter std::num_put<_CharT, _OutIter>::do_put(_OutIter, std::ios_base&, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iterator<char, std::char_traits<char> >]' /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4/bits/locale_facets.h:2350: instantiated from '_OutIter std::num_put<_CharT, _OutIter>::put(_OutIter, std::ios_base&, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iterator<char, std::char_traits<char> >]' /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4/bits/ostream.tcc:251: instantiated from 'std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(double) [with _CharT = char, _Traits = std::char_traits<char>]' tools_entropy_huffman.cpp:245: instantiated from here /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4/x86_64-pc-linux-gnu/bits/c++locale.h:84: warning: format not a string literal, argument types not checked /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/include/g++-v4/x86_64-pc-linux-gnu/bits/c++locale.h:84: warning: format not a string literal, argument types not checked make[6]: *** [tools_entropy_huffman.lo] Error 1 make[6]: *** Waiting for unfinished jobs.... x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../include -D__TRACE_AND_STATS_ -D__DOUBLE_PRECISION_ -D_REENTRANT -DNOCONTROLS -fexceptions -Wall -Werror -D_OBSS_ -Wall -Wno-char-subscripts -Woverloaded-virtual -Wno-unknown-pragmas -Wno-deprecated -Wformat=2 -march=athlon64 -Os -fomit-frame-pointer -ftracer -pipe -ftree-vectorize -Wformat=2 -DMPEG4IP -I/usr/include/SDL -D_REENTRANT -MT tools_sadct_sadct.lo -MD -MP -MF .deps/tools_sadct_sadct.Tpo -c tools_sadct_sadct.cpp -o tools_sadct_sadct.o >/dev/null 2>&1 make[5]: *** [all-recursive] Error 1 make[4]: *** [all] Error 2 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 !!! ERROR: media-video/mpeg4ip-1.4.1 failed. !!! Function src_compile, Line 124, Exitcode 2 !!! make failed !!! If you need support, post the topmost build error, NOT this status message.
Why not just patch the apps triggering this to have "#pragma GCC system_header" in the offending header files? In case this is still a problem that is...
Because it's not the apps' fault but compiler's fault
the offending header files already have that pragma ;)
I can reproduce it also with -Os at least
Known issue upstream.
Whenever it gets resolved upstream I'll add the patch.
Wasn't that the case of the patch that hanged the way array ere handled and we said it wasn't important enough to risk it?
This exact instance is, but it is a general problem. (Check the linked bug in the URL)
