Package: automake;
Reported by: Eric Blake <eblake <at> redhat.com>
Date: Wed, 11 Mar 2015 16:08:02 UTC
Severity: normal
Done: Karl Berry <karl <at> freefriends.org>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: help-debbugs <at> gnu.org (GNU bug Tracking System) To: Eric Blake <eblake <at> redhat.com> Subject: bug#20082: closed (Re: bug#20082: new warning from ar on rawhide systems) Date: Tue, 21 Nov 2023 16:49:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report #20082: default ARFLAGS=cru causes warnings when binutils is configured with --enable-deterministic-archives which was filed against the automake package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 20082 <at> debbugs.gnu.org. -- 20082: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20082 GNU Bug Tracking System Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Karl Berry <karl <at> freefriends.org> To: praiskup <at> redhat.com Cc: 20082 <at> debbugs.gnu.org Subject: Re: bug#20082: new warning from ar on rawhide systems Date: Tue, 21 Nov 2023 09:48:06 -0700> And the patch against Automake attached now, sorry for the delay. https://lists.gnu.org/archive/html/automake-patches/2016-03/msg00000.html In the better-late-than-never department: after eight years, I've finally applied this patch to make Automake's default ARFLAGS be cru instead of cr. (Modulo a few minor wording tweaks.) Thanks for the patch and the careful explanations. (And thanks to Bogdan for unearthing this one in the archives.) --best, karl. ----- From: Pavel Raiskup <praiskup <at> redhat.com> Date: Tue, 21 Nov 2023 08:30:00 -0800 Subject: [PATCH] automake: make the ARFLAGS default 'cr' instead of 'cru'. In some GNU/Linux distributions people started to compile 'ar' binary with --enable-deterministic-archives (binutils project). That, however, in combination with our previous long time working default AR_FLAGS=cru causes warnings on such installations: ar: `u' modifier ignored since `D' is the default (see `U') The 'u' option (at least with GNU binutils) did small optimization during repeated builds because it instructed 'ar' to not open/close unchanged *.o files and to rather read their contents from old archive file. However, its removal should not cause a big performance hit for usual workflows. Distributions started using --enable-deterministic-archives knowing that it would disable the 'u', just to rather have a bit more deterministic builds. Also, to justify this change a bit more, keeping 'u' in ARFLAGS could only result in many per-project changes to override Automake's ARFLAGS default, just to silence such warnings. Fixes bug#20082. Reported by Eric Blake. * bin/automake.in (handle_libraries): Use 'ARFLAGS=cr' by default. * doc/automake.texi (Building a library): Mention the changed ARFLAGS default. (@c LocalWords): Replace 'cru' with 'cr'. * m4/ar-lib.m4 (AM_PROG_AR): Cut out 'cru' string into separate ARFLAGS variable with new default 'cr'. * NEWS: Document. --- NEWS | 5 ++++- bin/automake.in | 2 +- doc/automake.texi | 4 ++-- m4/ar-lib.m4 | 3 ++- 4 files changed, 9 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index d9c8640ff..2a58785f3 100644 --- a/NEWS +++ b/NEWS @@ -10,6 +10,9 @@ New in 1.17: - AM_PATH_PYTHON will also search for Python versions 3.10 - 3.15. It has previously searched for 3.0 - 3.9. (bug#53530) + - The default value of $ARFLAGS is now "cr" instead of "cru", to + support deterministic builds. (bug#20082) + - RANLIB may be overridden on a per-target basis. - AM_TEXI2FLAGS may be defined to pass extra flags to TEXI2DVI & TEXI2PDF. @@ -69,7 +72,7 @@ New in 1.17: - Pass any options given to AM_PROG_LEX on to AC_PROG_LEX. (bug#65600 and bug#65730) -* Obsolescent features: +* Obsolescence: - py-compile no longer supports Python 0.x or 1.x versions. Python 2.0, released in 2000, is currently the minimum required version. diff --git a/bin/automake.in b/bin/automake.in index edc0488b8..c0ffc1986 100644 --- a/bin/automake.in +++ b/bin/automake.in @@ -2674,7 +2674,7 @@ sub handle_libraries () } define_variable ('AR', 'ar', INTERNAL); - define_variable ('ARFLAGS', 'cru', INTERNAL); + define_variable ('ARFLAGS', 'cr', INTERNAL); define_verbose_tagvar ('AR'); foreach my $pair (@liblist) diff --git a/doc/automake.texi b/doc/automake.texi index 635bdd28c..af8dd836f 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -5181,7 +5181,7 @@ library and the list of objects, and finally by calling @code{RANLIB} (Automake will complain otherwise). You should also call @code{AM_PROG_AR} to define @code{AR}, in order to support unusual archivers such as Microsoft lib. @code{ARFLAGS} will default to -@code{cru}; you can override this variable by setting it in your +@code{cr}; you can override this variable by setting it in your @file{Makefile.am} or by @code{AC_SUBST}ing it from your @file{configure.ac}. You can override the @code{AR} variable by defining a per-library @code{maude_AR} variable (@pxref{Program and @@ -13625,7 +13625,7 @@ attach the @file{test-suite.log} file. @c LocalWords: Miller's installable includedir inc pkgdata EXEEXT libexec bsd @c LocalWords: pkglib libexecdir prog libcpio cpio's dlopen dlpreopen linux @c LocalWords: subsubsection OBJEXT esac lib LTLIBRARIES liblob LIBADD AR ar -@c LocalWords: ARFLAGS cru ing maude libgettext lo LTLIBOBJS rpath SGI PRE yy +@c LocalWords: ARFLAGS cr ing maude libgettext lo LTLIBOBJS rpath SGI PRE yy @c LocalWords: libmaude CCLD CXXFLAGS FFLAGS LFLAGS OBJCFLAGS RFLAGS DEFS cc @c LocalWords: OBJCXXFLAGS @c LocalWords: SHORTNAME vtable srcdir nostdinc basename yxx cxx ll lxx gdb diff --git a/m4/ar-lib.m4 b/m4/ar-lib.m4 index f55b65019..e655b26f4 100644 --- a/m4/ar-lib.m4 +++ b/m4/ar-lib.m4 @@ -18,12 +18,13 @@ AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl AC_REQUIRE_AUX_FILE([ar-lib])dnl AC_CHECK_TOOLS([AR], [ar lib "link -lib"], [false]) : ${AR=ar} +: ${ARFLAGS=cr} AC_CACHE_CHECK([the archiver ($AR) interface], [am_cv_ar_interface], [AC_LANG_PUSH([C]) am_cv_ar_interface=ar AC_COMPILE_IFELSE([AC_LANG_SOURCE([[int some_variable = 0;]])], - [am_ar_try='$AR cru libconftest.a conftest.$ac_objext >&AS_MESSAGE_LOG_FD' + [am_ar_try='$AR $ARFLAGS libconftest.a conftest.$ac_objext >&AS_MESSAGE_LOG_FD' AC_TRY_EVAL([am_ar_try]) if test "$ac_status" -eq 0; then am_cv_ar_interface=ar -- 2.39.3 compile finished at Tue Nov 21 08:47:03 2023
[Message part 3 (message/rfc822, inline)]
From: Eric Blake <eblake <at> redhat.com> To: bug-automake <at> gnu.org Subject: new warning from ar on rawhide systems Date: Wed, 11 Mar 2015 10:07:33 -0600[Message part 4 (text/plain, inline)]When compiling libvirt (and probably other packages) on Fedora rawhide systems, I'm seeing a new warning message on every link line. # rpm -q libtool gcc binutils libtool-2.4.6-1.fc23.x86_64 gcc-5.0.0-0.16.fc23.x86_64 binutils-2.25-6.fc23.x86_64 For an example of the warning during a 'make V=1': > libtool: link: rm -fr .libs/libvirt_driver_qemu_impl.a .libs/libvirt_driver_qemu_impl.la > libtool: link: ar cru .libs/libvirt_driver_qemu_impl.a qemu/.libs/libvirt_driver_qemu_impl_la-qemu_agent.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_capabilities.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_command.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_domain.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_cgroup.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hostdev.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hotplug.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_conf.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_process.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_migration.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_text.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_json.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_driver.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_interface.o > ar: `u' modifier ignored since `D' is the default (see `U') > libtool: link: ranlib .libs/libvirt_driver_qemu_impl.a Reading 'man ar', it looks like a relatively new binutils invention, one that Fedora chose to flip on by default, but also one that might be worth using even when ar is built with 'U' rather than 'D' as the default: > D Operate in deterministic mode. When adding files and the archive > index use zero for UIDs, GIDs, timestamps, and use consistent file > modes for all files. When this option is used, if ar is used with > identical options and identical input files, multiple runs will > create identical output files regardless of the input files' > owners, groups, file modes, or modification times. > > If binutils was configured with --enable-deterministic-archives, > then this mode is on by default. It can be disabled with the U > modifier, below. Is it worth teaching automake to change ARFLAGS to be 'crD' instead of 'cru' when it is detected that ar is new enough to support deterministic libraries, in part to shut up the warning message being printed on every single libtool link line? (Note that I would explicitly include 'D', because even though Fedora chose to make 'D' the default, other distros may choose to make 'U' the default). Or conversely, do we want ARFLAGS to be 'cruU', to force non-deterministic mode, since any speedups made possible by timestamp comparison ('u') are only possible in non-deterministic mode? Does the use of 'u' buy us much measurable time when repeatedly and incrementally linking large libraries, where the new 'D' mode is forced to link everything instead of just the new inputs? And of course there's the question of how easy is it to detect that ar is new enough to understand the 'D'/'U' dichotomy? I've already asked on libtool, and they suggested it is an automake issue. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org[signature.asc (application/pgp-signature, attachment)]
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.