On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote:
> To gnulib guys: I haven't done proper analysis yet. Is the
> gl_PROG_AR_RANLIB really expected to be called for *each* 'gnulib'
> dependant project? If yes, could we possibly at least set the ARFLAGS
> default value to 'cr' instead of 'cru'? See [1,2] for context.
This becomes painfully complicated, sorry to bothering you - just trying
to make this ARFLAGS/AR_FLAGS mess resolved. I would appreciate any help.
Seems like the gl_PROG_AR_RANLIB was added by commit 2b14869442bc.
Do you think the attached gnulib patches are reasonable then? First makes
the gl_PROG_AR_RANLIB a bit more conservative and the second sets the
ARFLAGS default to 'cr'.
Pavel
>From 4631a59ef8edb1e499c13a72f61d318aa665bbad Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <prais...@redhat.com>
Date: Wed, 1 Jul 2015 09:06:49 +0200
Subject: [PATCH 1/2] gnulib-common.m4: fix gl_PROG_AR_RANLIB/AM_PROG_AR clash
The gl_PROG_AR_RANLIB (it is always called by gl_EARLY) sets AR
and ARFLAGS variables. Doing this unconditionally could brake
latter Automake's AM_PROG_AR invocation (at least it's
AC_CHECK_TOOLS call to detect 'ar' binary).
Original purpose of the gl_PROG_AR_RANLIB was only to handle the
Amsterdam Compiler Kit, so make the code to have effects only on
ACK, let the AM_PROG_AR decide other cases.
* m4/gnulib-common.m4 (gl_PROG_AR_RANLIB): AC_BEFORE AM_PROG_AR.
Set the AR/ARFLAGS to ACK defaults OR call AM_PROG_AR. If neither
is possible, keep setting AR/ARFLAGS to reasonable defaults.
---
m4/gnulib-common.m4 | 43 ++++++++++++++++++++++++++++---------------
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index b301abe..613e8d5 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -253,9 +253,10 @@ AC_DEFUN([gl_PROG_AR_RANLIB],
[
dnl Minix 3 comes with two toolchains: The Amsterdam Compiler Kit compiler
dnl as "cc", and GCC as "gcc". They have different object file formats and
- dnl library formats. In particular, the GNU binutils programs ar, ranlib
+ dnl library formats. In particular, the GNU binutils programs ar and ranlib
dnl produce libraries that work only with gcc, not with cc.
AC_REQUIRE([AC_PROG_CC])
+ AC_BEFORE([$0], [AM_PROG_AR])
AC_CACHE_CHECK([for Minix Amsterdam compiler], [gl_cv_c_amsterdam_compiler],
[
AC_EGREP_CPP([Amsterdam],
@@ -267,25 +268,37 @@ Amsterdam
[gl_cv_c_amsterdam_compiler=yes],
[gl_cv_c_amsterdam_compiler=no])
])
- if test -z "$AR"; then
- if test $gl_cv_c_amsterdam_compiler = yes; then
+
+ dnl Don't compete with AM_PROG_AR's decission about AR/ARFLAGS if we are not
+ dnl building with __ACK__.
+ if test $gl_cv_c_amsterdam_compiler = yes; then
+ if test -z "$AR"; then
AR='cc -c.a'
- if test -z "$ARFLAGS"; then
- ARFLAGS='-o'
- fi
- else
- dnl Use the Automake-documented default values for AR and ARFLAGS,
- dnl but prefer ${host}-ar over ar (useful for cross-compiling).
- AC_CHECK_TOOL([AR], [ar], [ar])
- if test -z "$ARFLAGS"; then
- ARFLAGS='cru'
- fi
fi
- else
if test -z "$ARFLAGS"; then
- ARFLAGS='cru'
+ ARFLAGS='-o'
fi
+ else
+ dnl AM_PROG_AR was added in automake v1.11.2. AM_PROG_AR does not AC_SUBST
+ dnl ARFLAGS variable (it is filed into Makefile.in directly by automake
+ dnl script on-demand, if not specified by ./configure of course).
+ dnl Don't AC_REQUIRE the AM_PROG_AR otherwise the code for __ACK__ above
+ dnl will be ignored. Also, pay attention to call AM_PROG_AR in else block
+ dnl because AM_PROG_AR is written so it could re-set AR variable even for
+ dnl __ACK__. It may seem like its easier to avoid calling the macro here,
+ dnl but we need to AC_SUBST both AR/ARFLAGS (thus those must have some good
+ dnl default value and automake should usually know them).
+ m4_ifdef([AM_PROG_AR], [AM_PROG_AR], [:])
fi
+
+ dnl In case the code above have not helped with setting AR/ARFLAGS, use
+ dnl Automake-documented default values for AR and ARFLAGS, but prefer
+ dnl ${host}-ar over ar (useful for cross-compiling).
+ AC_CHECK_TOOL([AR], [ar], [ar])
+ if test -z "$ARFLAGS"; then
+ ARFLAGS='cru'
+ fi
+
AC_SUBST([AR])
AC_SUBST([ARFLAGS])
if test -z "$RANLIB"; then
--
2.1.0
>From 64d95effe459f7e7b02834a6ad1d7e5e092581a0 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <prais...@redhat.com>
Date: Wed, 1 Jul 2015 09:38:35 +0200
Subject: [PATCH 2/2] gnulib-common.m4: change the ARFLAGS default to 'cr'
In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with previous autotools 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 will disable the 'u', with the benefit of having
rather 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 silent such warnings.
* m4/gnulib-common.m4 (gl_PROG_AR_RANLIB): Set ARFLAGS='cr' if not
set already.
---
m4/gnulib-common.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index 613e8d5..34d0f20 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -296,7 +296,7 @@ Amsterdam
dnl ${host}-ar over ar (useful for cross-compiling).
AC_CHECK_TOOL([AR], [ar], [ar])
if test -z "$ARFLAGS"; then
- ARFLAGS='cru'
+ ARFLAGS='cr'
fi
AC_SUBST([AR])
--
2.1.0
