emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20082: closed (default ARFLAGS=cru causes warnings when binutils is


From: GNU bug Tracking System
Subject: bug#20082: closed (default ARFLAGS=cru causes warnings when binutils is configured with --enable-deterministic-archives)
Date: Tue, 21 Nov 2023 16:49:02 +0000

Your message dated Tue, 21 Nov 2023 09:48:06 -0700
with message-id <202311211648.3ALGm6hr001820@freefriends.org>
and subject line Re: bug#20082: new warning from ar on rawhide systems
has caused the debbugs.gnu.org bug report #20082,
regarding default ARFLAGS=cru causes warnings when binutils is configured with 
--enable-deterministic-archives
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
20082: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20082
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: new warning from ar on rawhide systems Date: Wed, 11 Mar 2015 10:07:33 -0600 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
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



Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
--- Begin Message --- 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@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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]