Hello,
I've found apart of the reason, for xz:
libtool 2.4.2 2.4.5(before patched) (after patched)
make -j1 9s 19s 11s
Remove the following lines from libtool, then the compile will be
much faster, the problem is the variable like $host, $SHELL in
the long_help_message would make shell very slow:
=== Removed lines ===
# Additional text appended to 'usage_message' in response to '--help'.
long_help_message=$long_help_message"
MODE must be one of the following:
clean remove files from the build directory
compile compile a source file into a libtool object
execute automatically set library path, then run a program
finish complete the installation of libtool libraries
install install libraries or executables
link create a library or an executable
uninstall remove libraries from an installed directory
MODE-ARGS vary depending on the MODE. When passed as first option,
'--mode=MODE' may be abbreviated as 'MODE' or a unique abbreviation of that.
Try '$progname --help --mode=MODE' for a more detailed description of MODE.
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`
Report bugs to <bug-libt...@gnu.org>.
GNU libtool home page: <http://www.gnu.org/software/libtool/>.
General help using GNU software: <http://www.gnu.org/gethelp/>."
==================
I think that another 2s gaps is caused by:
func_hookable func_options
func_options ()
{
$debug_cmd
func_options_prep ${1+"$@"}
eval func_parse_options \
${func_options_prep_result+"$func_options_prep_result"}
eval func_validate_options \
${func_parse_options_result+"$func_parse_options_result"}
eval func_run_hooks func_options \
${func_validate_options_result+"$func_validate_options_result"}
# save modified positional parameters for caller
func_options_result=$func_run_hooks_result
}
mainly because of:
eval func_parse_options \
${func_options_prep_result+"$func_options_prep_result"}
I'm still trying to figure out why.
// Robert
On 02/04/2015 09:11 AM, Robert Yang wrote:
On 02/03/2015 10:31 PM, Bob Friesenhahn wrote:
On Tue, 3 Feb 2015, Robert Yang wrote:
Sorry, I was wrong, tt seems that libtoolize is not the key, but libtool,
when compile cairo-1.12.18:
libtool 2.4.2 libtool 2.4.5
configure: 31s 32s
compile: 54s 64s
The libtool 2.4.5 costs 10 more seconds. I'm debugging on it, any suggestion
is appreciated.
The build slowdown must not be my imagination then. I had attributed the
slowdown to other factors. Recently I noticed that build times for my own
project were significantly longer than I remember.
Previously libtool was heavily optimized to reduce the number of forks
(execution of child process). This optimization should still be present in
2.4.2. Any additional forks will result in a slower build.
It is not necessary to libtoolize a package in order to test its build
performance with different libtool versions. You can specify LIBTOOL in the
environment (see the Makefiles) such that it points to the uninstalled libtool
in a libtool build tree.
We run autoreconf for the package automatically to make sure that we can
build most of the autotools packages successfully, and autoreconf will
run libtoolize when needed, if we don't run autoreconf, then a few of the
packages will fail to build, now we upgrade libtool from 2.4.2 to 2.4.4/2.4.5,
it takes more time to build, I will try 2.4.3.
// Robert
Bob
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool