My RHEL-6 gcc (4.4.7) complains a lot about it:
cc1: warning: command line option "-Wenum-compare" is
valid for C++/ObjC++ but not for C
For older gcc version (e.g. 4.4.7), man gcc says
-Wenum-compare is "C++ and Objective-C++ only".
For newer gcc (e.g. 4.9.2), man gcc says
"In C this warning is enabled by -Wall."
This commit reuse several macros from libvirt to test for
support for "-Wl,-z -Wl,relro", "-Wl,-z -Wl,now" and
"-Wl,--no-copy-dt-needed-entries", and use them if available.
If the _FORTIFY_SOURCE has been already defined, we shouldn't redefine
it, or it will raise a build error as below:
In file included from agent-msg-filter.c:21:0:
../config.h:17:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
agent-msg-filter.c:1:0: note: this is the location of the previous definition
Suggested-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Dunrong Huang <riegamaths@gmail.com>
Fix copied from libvirt, commit by Eric Blake.
glibc 2.15 (on Fedora 17) coupled with explicit disabling of
optimization during development dies a painful death:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
Work around this by only conditionally defining _FORTIFY_SOURCE,
in the case where glibc can actually use it. The trick is using
AH_VERBATIM instead of AC_DEFINE.
The API design of SLIRP means that it is not practical to use
the -Waggregate-return warning flag. Disable this flag in the
(unlikely) scenario where SLIRP is actually requested at build
time
* m4/manywarnings.m4m, m4/warnings.m4: Import GNULIB warnings
modules
* m4/spice-compile-warnings.m4: Define SPICE_COMPILE_WARNINGS
* configure.ac: Replace compile warning check with a call to
SPICE_COMPILE_WARNINGS
* client/Makefile.am: Use WARN_CXXFLAGS instead of WARN_CFLAGS
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
