On RHEL 6.2, gcc 4.4.6 complains:
cc1: warning: command line option "-Wenum-compare" is valid for C++/ObjC++ but not for C
which in turn breaks a -Werror build.

Meanwhile, in Fedora 17, gcc 4.7.0, -Wenum-compare has been enhanced
to also work on C, but at the same time, it is documented that -Wall
now implicitly includes -Wenum-compare.

Therefore, it is sufficient to remove explicit checks for this option,
avoiding the warning from older gcc while still getting the
compile-time safety from newer gcc.

* m4/virt-compile-warnings.m4 (-Wenum-compare): Omit explicit check.

OpenBSD ships with gcc 4.2.1, which annoyingly treats all format
strings as though they were also attribute((nonnull)).  The two
concepts are orthogonal, though, as evidenced by the number of
spurious warnings it generates on uses where we know that
virReportError specifically handles NULL instead of a format
string; worse, since we now force -Werror on git builds, it
prevents development builds on OpenBSD.

I hate to do this, as it disables ALL format checking on older
gcc, and therefore misses out on some useful checks (code that
happened to compile on Linux may still have type mismatches
when compiled on other platforms, as evidenced by the number
of times I have fixed formatting mismatches for uid_t as found
by warnings on Cygwin), but I don't see any other way to keep
-Werror alive and still compile on OpenBSD.

A more invasive change would be to make virReportError() mark
its format attribute as nonnull, and fix (a lot of) fallout;
we may end up doing that anyways as part of danpb's error
refactoring improvements, but not today.

* src/internal.h (ATTRIBUTE_FMT_PRINTF): Use preferred spellings.
* m4/virt-compile-warnings.m4 (-Wformat): Disable on older gcc.

A previous patch (c606671a) pulled in a newer version of
stat-time.h from gnulib, which causes some warnings in older gcc:

  CC     libvirt_driver_storage_la-storage_backend.lo
cc1: warnings being treated as errors
In file included from ../../src/storage/storage_backend.c:59:
../../gnulib/lib/stat-time.h:55: error: no previous prototype for 'get_stat_atime_ns' [-Wmissing-prototypes]

Upstream gnulib argues that these warnings are stupid (and I agree;
see <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54113>), and has
used a modern gcc feature (#pragma GCC diagnostic push) to avoid the
warning.  But we still aim to compile on RHEL 6.3, with gcc 4.4.6
(not to mention even older platforms like RHEL 5), and therefore
the warning trips up our default of development with -Werror.

It took me a while to figure out how to make our set of warnings
smaller on older gcc without losing the benefit of the warnings
when using newer gcc (such as the one on Fedora 17), but this
should do the trick.

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Avoid
warnings that gnulib can't silence on older gcc.

The access, birth, modification and change times are added to
storage volumes and corresponding xml representations.  This
shows up in the XML in this format:

<timestamps>
  <atime>1341933637.027319099</atime>
  <mtime>1341933637.027319099</mtime>
</timestamps>
Signed-off-by: NEric Blake <eblake@redhat.com>

While libvirt intentionally avoids -Wundef (after all, C99
guarantees sane semantics of treating undefined macros as 0),
the glibc insanity of #warning on _FORTIFY_SOURCE coupled with
what some people feel is the black magic of autoconf means
that other projects are likely to copy our snippet verbatim.
We can be nicer to other projects by making it easier to
integrate into projects that use -Wundef.

Suggested by Christophe Fergeau.

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Be nice
to other projects using -Wundef.

glibc 2.15 (on Fedora 17) coupled with explicit disabling of
optimization during development dies a painful death:

In file included from /usr/include/limits.h:27:0,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include/limits.h:169,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/include/limits.h:34,
                 from util/bitmap.c:26:
/usr/include/features.h:314:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
cc1: all warnings being treated as errors

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.

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Squelch
_FORTIFY_SOURCE when needed to avoid glibc #warnings.

Given that we auto-detect whether each -Wxxxx flag is supported by
GCC, and we are warning-free and use automake silent rules, there
is no compelling reason to allow compile warnings to be disabled.

Replace the --enable-compile-warnings flag with a simpler
--enable-werror flag, which defaults to 'yes' if building
from GIT, or 'no' if building from tar.gz

This helps ensure that everyone writing patches for libvirt will
take care to fix their warning problems before submitting for
review

* autobuild.sh: Force -Werror
* configure.ac: Update for LIBVIRT_COMPILE_WARNINGS macro change
* m4/virt-compile-warnings.m4: Permanently enable all warnings,
  auto-enable Werror for GIT builds

Gnulib claims that there are some classes of warnings that are
worth enabling during development, but where silencing those
warnings causes code bloat that is not necessary in an optimized
build.  The code bloat to silence the warnings is only enabled
by -Dlint.  Follow the lead of coreutils in setting up -Dlint
whenever full warnings are requested.

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Add
-Dlint, and move _FORTIFY_SOURCE to config.h instead of CFLAGS.

Older gcc warns (on every file!) that -Wabi and -Wdeprecated only
make sense on C++ projects.  Newer gcc accepts these warnings for
C, but it is not clear that they can do anything useful, so it
is easier to just drop the warnings altogether.

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Silence
-Wabi and -Wdeprecated on older gcc.
Reported by Peter Krempa.

I had previously tested commit 059d746d with -O intentionally omitted
from my CFLAGS; but that means that I missed out on this warning
from gcc 4.6.2 when optimizations are enabled:

util/buf.c: In function 'virBufferGetIndent':
util/buf.c:86:1: error: function might be candidate for attribute 'pure' [-Werror=suggest-attribute=pure]

While it is probably a good idea to add the attributes and silence
this warning, it's also invasive; 'make -k' found more than 75 such
complaints.  And it doesn't help that gcc 4.6.2 is still buggy
(coreutils reported a case where gcc 4.6.2 incorrectly suggested
marking a function pure that incremented a global variable; fixed
in gcc 4.7).  So the best fix for now is to disable the warning.

It also doesn't help that I stumbled across another problem - gcc
documents that -Wsuggest-attribute=pure only warns if you use -O,
or if you use -fipa-pure-const.  But in practice, when I omitted -O
but added -fipa-pure-const, the warnings are fickle - I got warnings
for simple compilation that disappeared when I also added -fPIC.
And the way libtool compiles things is with -fPIC first, then without
-fPIC but with errors sent to /dev/null - which meant that without
disabling -Wsuggest-attribute=pure, I got a compile error with no
message.  :(  See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10197

* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Silence
-Wsuggest-attribute warnings for now.

* .gnulib: Update to latest, for improved 'make syntax-check' and
compiler warnings.
* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS):
Re-silence -Wformat-nonliteral.
* cfg.mk (_test_script_regex): Recognize our test scripts.
* gnulib/local/lib/*.diff: Drop, now that gnulib has this.
* tests/virsh-optparse: Fix use of compare.
* tests/virsh-schedinfo: Likewise.

Make virtTestLoadFile allocate the buffer to read the file into.

Fix logic error in virtTestLoadFile, stop reading on the first empty line.

Use virFileReadLimFD in virtTestCaptureProgramOutput to avoid manual
buffer handling.

Make it so we don't have to 'git add -f' particular files like
po/POTFILES.in all the time (tested by fixing one of our
special-case files as part of the patch).

* .gnulib: Update to latest.
* bootstrap: Resync from coreutils.
* .gitignore: Sort whitelist entries correctly, including ignoring
files rather than directories.
* m4/virt-compile-warnings.m4: Convert tabs to space.

With gcc 4.3.4 I'm seeing the following warning failure

cc1: warnings being treated as errors
cc1: error: -funit-at-a-time is required for inlining of functions
that are only called once [-Wdisabled-optimization]

Add -funit-at-a-time to WARN_CFLAGS.

The GCC Win32 compiler will claim to support -fstack-protector,
but if it actually gets triggered by a suitable code pattern,
linking will fail. Other non-Linux OS likely suffer the same
way with gcc.

* m4/virt-compile-warnings.m4: Only use stack protector when
  the build target is Linux.

A couple of functions were declared using the old style foo()
for no-parameters, instead of foo(void)

* src/xen/xen_hypervisor.c, tests/testutils.c: Replace () with (void)
  in some function declarations
* m4/virt-compile-warnings.m4: Enable -Wold-style-definition

* src/internal.h: Define a ATTRIBUTE_NO_RETURN annotation
* src/lxc/lxc_container.c: Annotate lxcContainerDummyChild
  with ATTRIBUTE_NO_RETURN
* tests/eventtest.c: Mark async thread as ATTRIBUTE_NO_RETURN
* m4/virt-compile-warnings.m4: Enable -Wmissing-noreturn

Add a couple of missing ATTRIBUTE_FMT_PRINTF annotations

* tools/virsh.c, tests/testutils.c: Add printf format attribute
* m4/virt-compile-warnings.m4: Enable -Wmissing-format-attribute

Split the bit acinclude.m4 file into smaller pieces named
as m4/virt-XXXXX.m4

* .gitignore: Ignore gettext related files
* acinclude.m4: Delete
* m4/virt-compile-warnings.m4: Checks for GCC compiler flags
* m4/virt-pkgconfig-back-compat.m4: Backcompat check for
  pkgconfig program

Remove custom code for checking compiler warnings, using
gl_WARN_ADD instead. Don't list all flags ourselves, use
gnulib's gl_MANYWARN_ALL_GCC to get all possible GCC flags,
then turn off the ones we don't want yet.

* acinclude.m4: Rewrite to use gl_WARN_ADD and gl_MANYWARN_ALL_GCC
* bootstrap.conf: Add warnings & manywarnings
* configure.ac: Switch to gl_WARN_ADD
* m4/compiler-flags.m4: Obsoleted by gl_WARN_ADD

Even with -Wuninitialized (which is part of autobuild.sh
--enable-compile-warnings=error), gcc does NOT catch this
use of an uninitialized variable:

{
  if (cond)
    goto error;
  int a = 1;
error:
  printf("%d", a);
}

which prints 0 (supposing the stack started life wiped) if
cond was true.  Clang will catch it, but we don't use clang
as often.  Using gcc -Wjump-misses-init catches it, but also
gives false positives:

{
  if (cond)
    goto error;
  int a = 1;
  return a;
error:
  return 0;
}

Here, a was never used in the scope of the error block, so
declaring it after goto is technically fine (and clang agrees).
However, given that our HACKING already documents a preference
to C89 decl-before-statement, the false positive warning is
enough of a prod to comply with HACKING.

[Personally, I'd _really_ rather use C99 decl-after-statement
to minimize scope, but until gcc can efficiently and reliably
catch scoping and uninitialized usage bugs, I'll settle with
the compromise of enforcing a coding standard that happens to
reject false positives if it can also detect real bugs.]

* acinclude.m4 (LIBVIRT_COMPILE_WARNINGS): Add -Wjump-misses-init.
* src/util/util.c (__virExec): Adjust offenders.
* src/conf/domain_conf.c (virDomainTimerDefParseXML): Likewise.
* src/remote/remote_driver.c (doRemoteOpen): Likewise.
* src/phyp/phyp_driver.c (phypGetLparNAME, phypGetLparProfile)
(phypGetVIOSFreeSCSIAdapter, phypVolumeGetKey)
(phypGetStoragePoolDevice)
(phypVolumeGetPhysicalVolumeByStoragePool)
(phypVolumeGetPath): Likewise.
* src/vbox/vbox_tmpl.c (vboxNetworkUndefineDestroy)
(vboxNetworkCreate, vboxNetworkDumpXML)
(vboxNetworkDefineCreateXML): Likewise.
* src/xenapi/xenapi_driver.c (getCapsObject)
(xenapiDomainDumpXML): Likewise.
* src/xenapi/xenapi_utils.c (createVMRecordFromXml): Likewise.
* src/security/security_selinux.c (SELinuxGenNewContext):
Likewise.
* src/qemu/qemu_command.c (qemuBuildCommandLine): Likewise.
* src/qemu/qemu_hotplug.c (qemuDomainChangeEjectableMedia):
Likewise.
* src/qemu/qemu_process.c (qemuProcessWaitForMonitor): Likewise.
* src/qemu/qemu_monitor_text.c (qemuMonitorTextGetPtyPaths):
Likewise.
* src/qemu/qemu_driver.c (qemudDomainShutdown)
(qemudDomainBlockStats, qemudDomainMemoryPeek): Likewise.
* src/storage/storage_backend_iscsi.c
(virStorageBackendCreateIfaceIQN): Likewise.
* src/node_device/node_device_udev.c (udevProcessPCI): Likewise.

This would have detected the bug in commit 38ad33931 (Aug 09), which
we missed until commit f828ca35 (Jul 10); over 11 months later.

However, on Fedora 13, it also triggers LOTS of warnings from
the libcurl-devel header for two files:

esx/esx_vi.c: In function 'esxVI_CURL_Perform':
esx/esx_vi.c:232: error: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op]
esx/esx_vi.c:232: error: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op]
esx/esx_vi.c:232: error: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op]
...
xenapi/xenapi_driver.c: In function 'call_func':
xenapi/xenapi_driver.c:1872: error: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op]
xenapi/xenapi_driver.c:1872: error: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op]
xenapi/xenapi_driver.c:1872: error: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op]
...

libcurl allows to disable the type-checking code that triggers those
warnings, along with the reduction in type-safety of calls to some
libcurl functions. I figure this is worth the improved compiler
checking throughout the rest of libvirt.

* acinclude.m4 (--enable-compile-warnings=error): Add -Wlogical-op.
* configure.ac: Add -DCURL_DISABLE_TYPECHECK to LIBCURL_CFLAGS to
avoid compilation warning.

Suggested by Daniel P. Berrange.
Tweaked by Matthias Bolte.

Matthias noted that the line:
virt_aa_helper_LDFLAGS = $(WARN_CFLAGS)
looks inconsistent, so I did an audit.

Currently, the set of compiler warning flags passed to gcc as $CC are
equally permitted as the set of linker flags passed to gcc as $LD, so
there was no problem with that usage.  But if we ever get in a
situation where $CC and $LD treat particular flags differently, using
the right variable form will make it easier.

In the process, I spotted a couple of typos that were omitting useful
flags, as well as specifying a -l under the wrong variable.

* acinclude.m4 (LIBVIRT_COMPILE_WARNINGS): Define WARN_LDFLAGS as
an alias for WARN_CFLAGS.
* tools/Makefile.am (virsh_LDFLAGS): Use more canonical spelling.
* proxy/Makefile.am (libvirt_proxy_LDFLAGS): Likewise. Move
library...
(libvirt_proxy_LDADD): ...here.
* src/Makefile.am (virt_aa_helper_LDFLAGS): Use more canonical
spelling of WARN_LDFLAGS.
(libvirt_parthelper_LDFLAGS, libvirt_lxc_LDFLAGS): Likewise.  Use
correct spelling of COVERAGE_LDFLAGS.
Reported by Matthias Bolte.

* acinclude.m4 (LIBVIRT_COMPILE_WARNINGS): Add
-fdiagnostics-show-option.

by running this command:
git ls-files -z | xargs -0 perl -pi -0777 -e 's/\n\n+$/\n/'
This is in preparation for a more strict make syntax-check
rule that will detect trailing blank lines.

        Avoid risk of format string abuse (also avoids gcc warnings).
        * src/util.c (ReportError): Use a literal "%s" format string.
        * src/remote_internal.c (server_error): Likewise.
        * src/qemu_conf.c (qemudReportError): Likewise.
        * acinclude.m4: Add -Wformat -Wformat-security to default
          list of warning flags, to warn about errors such as the
          above.

        * acinclude.m4, configure.in: ./configure option
          --disable-stack-protector.
        * src/gnutls_1_0_compat.h: Compatibility with GnuTLS 1.0.
        * src/bridge.c: If no bridge ioctls, give an error at runtime.

  user specified CFLAGS
Daniel

        * acinclude.m4: add LIBVIRT_COMPILE_WARNINGS, copied from
        GNOME but with a few more flags we'd been using.

        * configure.in: use that instead of setting CFLAGS
        directly.

        * proxy/Makefile.am, python/Makefile.am, qemud/Makefile.am,
          src/Makefile.am, tests/Makefile.am: use $(WARN_CFLAGS)