libtool
[Top][All Lists]
Advanced

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

Re: Performance issue of libtool-2.4.4


From: Gary V. Vaughan
Subject: Re: Performance issue of libtool-2.4.4
Date: Fri, 6 Feb 2015 12:52:55 +0000

Hi Peter,

On Feb 6, 2015, at 9:46 AM, Peter Rosin <address@hidden> wrote:
> On 2015-02-06 10:30, Gary V. Vaughan wrote:
>>> On Feb 6, 2015, at 9:22 AM, Peter Rosin <address@hidden> wrote:
>>> 
>>>> On 2015-02-04 15:48, Bob Friesenhahn wrote:
>>>>> On Wed, 4 Feb 2015, Robert Yang wrote:
>>>>> 
>>>>> When reporting a bug, please describe a test case to reproduce it and
>>>>> include the following information:
>>>>> 
>>>>>     host-triplet:   $host
>>>>>     shell:          $SHELL
>>>>>     compiler:       $LTCC
>>>>>     compiler flags: $LTCFLAGS
>>>>>     linker:         $LD (gnu? $with_gnu_ld)
>>>>>     version:        $progname (GNU libtool) 2.4.5
>>>>>     automake:       `($AUTOMAKE --version) 2>/dev/null |$SED 1q`
>>>>>     autoconf:       `($AUTOCONF --version) 2>/dev/null |$SED 1q`
>>>> 
>>>> Perhaps libtool is accidentially executing 'automake --version' and 
>>>> 'autoconf --version' every time it is executed?  That would certainly lead 
>>>> to a huge slowdown.
>>> 
>>> That's it of course, how else could the variable be assigned?
>> 
>> Only when --version is being serviced.
> 
> Are you saying the a script with this line in it:
>       foo="`($AUTOCONF --version)`"
> will delay the exec of $AUTOCONF until foo is expanded?
> 
> I think not.


I mean a script with this function in it won't run '$AUTOCONF --version' until 
and unless `libtool --help` is executed from the command line:

func_help ()
{
    $debug_cmd

    func_usage_message
    $ECHO "$long_help_message
...
       automake:       `($AUTOMAKE --version) 2>/dev/null |$SED 1q`             
               
       autoconf:       `($AUTOCONF --version) 2>/dev/null |$SED 1q`             
                                                                                
                              
...
"
    exit 0
}

Which is what I plan to commit before the next release.

>>> But is it even useful information? I would expect that the autofoo
>>> versions *at the time the package was created* is what matters?
>> 
>> The information is useful in bug reports, and our instructions for reporting 
>> a bug to the list explicitly ask for the output from `libtool --version` 
>> which by including their other autotool versions makes reproducing the 
>> reporters environment a lot easier :-)
> 
> But are the autofoo versions at libtool time really what we want
> to know in bug reports? Again, I'd be much more interested in the
> autofoo versions used to bootstrap the package. That might often
> be the same thing, but when they are not confusion will ensue.

Please propose (or commit!) a patch that fixes the regression, and also 
precisely demonstrates what you prefer :-)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


reply via email to

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