[Top][All Lists]

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

Re: Performance issue of libtool-2.4.4

From: Peter Rosin
Subject: Re: Performance issue of libtool-2.4.4
Date: Fri, 06 Feb 2015 10:22:52 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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?

But is it even useful information? I would expect that the autofoo
versions *at the time the package was created* is what matters?
Presenting some random autofoo version from the machine that runs
the libtool script is just bogus. The relevant versions are
certainly known when automake/autoconf are executed, but ever
since the ltmain.m4sh-> step is gone, is there even
a natural place for libtool to get to that info?

ho hum

The autoconf version can be grabbed from first lines of the
configure script, which certainly can be made available to the>libtool step. But how to get to the relevant
automake version? If automake is even used for the package in


reply via email to

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