bug-gnulib
[Top][All Lists]
Advanced

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

Re: [gnulib PATCH]: new warning from ar on rawhide systems


From: Pavel Raiskup
Subject: Re: [gnulib PATCH]: new warning from ar on rawhide systems
Date: Wed, 01 Jul 2015 17:22:34 +0200
User-agent: KMail/4.14.9 (Linux/4.0.5-200.fc21.x86_64+debug; KDE/4.14.9; x86_64; ; )

On Wednesday 01 of July 2015 15:19:15 Pádraig Brady wrote:
> On 01/07/15 14:57, Pavel Raiskup wrote:
> > On Wednesday 01 of July 2015 13:42:35 Pádraig Brady wrote:
> >>>> On 01/07/15 09:00, Pavel Raiskup wrote:
> >>> 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'.
> 
> >> With this I'm now getting this warning:
> >>
> >> configure.ac:59: warning: AC_COMPILE_IFELSE was called before 
> >> AC_USE_SYSTEM_EXTENSIONS
> >> ../../lib/autoconf/specific.m4:314: AC_GNU_SOURCE is expanded from...
> >> m4/gnulib-comp.m4:34: gl_EARLY is expanded from...
> >> configure.ac:59: the top level
> >>
> >> I see that gnulib-tool puts this very early on:
> >>
> >>   echo "  AC_REQUIRE([gl_PROG_AR_RANLIB])"
> > 
> > 
> > I might do something wrong, but ..  Firstly I was about to think that I
> > should always AC_REQUIRE([AM_PROG_AR]) (not directly call it), however
> > that does not resolve the ordering :(.
> 
> Yes the dependence is gl_PROG_AR_RANLIB -> AM_PROG_AR -> AC_COMPILE_IFELSE
> And gnulib-tool puts gl_PROG_AR_RANLIB at the start.
>
> > So to me, it rather looks (in case the gl_PROG_AR_RANLIB really has to be
> > called that early), we should also call very early
> > gl_USE_SYSTEM_EXTENSIONS (before gl_PROG_AR_RANLIB), conditionally if some
> > module requires that.
> > 
> > I'm not sure whether I analyzed that correctly, but it resolved the
> > ordering for coreutils (while still calling AM_PROG_AR).
> 
> That should work but seems complicated by the conditionality aspect.

Yes, there is still nothing like that in gnulib-tool, am I right?  I mean
dependency among configure.ac-early snippets -- those seem to be all just
sorted by name (by 'LANG=C sort -u').

Would you consider something like this as acceptable?

diff --git a/gnulib-tool b/gnulib-tool
index ec82f35..f5bddbb 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -5188,6 +5188,10 @@ s,//*$,/,'
     echo "  m4_pattern_allow([^gl_ES\$])dnl a valid locale name"
     echo "  m4_pattern_allow([^gl_LIBOBJS\$])dnl a variable"
     echo "  m4_pattern_allow([^gl_LTLIBOBJS\$])dnl a variable"
+
+    echo "$final_modules" | grep "^extensions$" >/dev/null \
+        && echo "  AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])"
+
     echo "  AC_REQUIRE([gl_PROG_AR_RANLIB])"
     if test -n "$uses_subdirs"; then
       echo "  AC_REQUIRE([AM_PROG_CC_C_O])"

I don't like that TBH, but if we planned to make the gl_PROG_AR_RANLIB
part of some module (and add some ordering into early snippets), this
would be enough for the meantime.

> I tested coreutils with just the s/cru/cr/ change, and it removed
> the "-u is ignored" warnings, so we can go with that one at least?

Yes.  That should help gnulib projects with the 'ar' warning issue in
F22+.  The AM_PROG_AR incompatibility may be fixed later..

Pavel




reply via email to

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