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

[Pádraig Brady]

On 01/07/15 16:22, Pavel Raiskup wrote:
> 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.

Yes that's a bit coupled but should work.
I'll try to test later.

>> 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..

thanks,
Pádraig.