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: Pádraig Brady
Subject: Re: [gnulib PATCH]: new warning from ar on rawhide systems
Date: Wed, 01 Jul 2015 15:19:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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

cheers,
Pádraig.



reply via email to

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