[libvirt] [PATCH] build: silence ar warnings on rawhide

Eric Blake eblake at redhat.com
Tue Jun 2 15:24:26 UTC 2015


Newer binutils 'ar' has added an option 'D' for deterministic
builds, and at least on rawhide, this option is enabled by default.
But it conflicts with the 'u' optimization where the linker only
modifies libraries based on file timestamps, but can result in
different library ordering based on which files were touched last.
Thus, it results in some noisy compilation, for every CCLD line:

  CCLD     libvirt_driver_qemu_impl.la
  ar: `u' modifier ignored since `D' is the default (see `U')

Upstream automake has decided that defaulting ARFLAGS to 'cru' is
no longer beneficial, and that switching the default to 'cr' will
both silence the noise and not penalize modern build systems.

https://lists.gnu.org/archive/html/automake-patches/2015-06/msg00000.html

But rather than wait for newer automake to propagate to all systems
that already have newer binutils, we might as well just use the new
default ourselves, even on older platforms.

Signed-off-by: Eric Blake <eblake at redhat.com>
---

This is bugging me even more now that Fedora 22 also suffers from
the same issue (we've been ignoring it in rawhide for several months
now).  While it seems trivial, I'd like a review before pushing.

 configure.ac | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/configure.ac b/configure.ac
index 0da3ae8..abf4436 100644
--- a/configure.ac
+++ b/configure.ac
@@ -25,6 +25,10 @@ AC_CONFIG_MACRO_DIR([m4])
 dnl Make automake keep quiet about wildcards & other GNUmake-isms; also keep
 dnl quiet about the fact that we intentionally cater to automake 1.9
 AM_INIT_AUTOMAKE([-Wno-portability -Wno-obsolete tar-ustar subdir-objects])
+dnl older automake's default of ARFLAGS=cru is noisy on newer binutils;
+dnl we don't really need the 'u' even in older toolchains.  Then there is
+dnl older libtool, which spelled it AR_FLAGS
+m4_divert_text([DEFAULTS], [: "${ARFLAGS=cr} ${AR_FLAGS=cr}"])

 # Maintainer note - comment this line out if you plan to rerun
 # GNULIB_POSIXCHECK testing to see if libvirt should be using more modules.
-- 
2.4.2




More information about the libvir-list mailing list