summaryrefslogtreecommitdiff
path: root/meta/recipes-devtools/libtool/libtool-2.4.5.inc
AgeCommit message (Collapse)AuthorFiles
2015-02-16libtool: 2.4.5 -> 2.4.6Richard Purdie1
Drop patch merged upstream. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-14libtool: don't execute automake and autoconf on every invocationRobert Yang1
From the origin commit message: Regression from 2.4.2 was causing noticable slow-down in builds that call libtool many times. * build-aux/ltmain.in (func_help): Override func_help() from gl/build-aux/options-parser to only run automake --version and autoconf --version when libtool --help is executed on the command line. Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
2015-02-14Revert "libtool: avoid running automake/autoconf --version"Robert Yang1
This reverts commit 1f53edeaf9ea59dd55459a6d5a93829fb4983839. There is a better fix on upstream, will backport it. Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
2015-02-10libtool: Fix option parsing performance regressionRichard Purdie1
Cut and paste the pieces of build-aux/options-parser inline into the main ltmain.sh code. This removes a performance degradation caused by the repeated calls to func_quote_for_eval, the mechanism funclib uses to construct the functions used for option parsing. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-05libtool: avoid running automake/autoconf --versionRobert Yang1
The libtool would be very slow if run "automake/autoconf --version", for example, when compile xz-native (make -j1, only compile, no confiure or install): before patched: 19s after patched: 11s Use plain text to instead of running them. NOTE: it is still a little slower than libtool 2.4.2 when compile xz-native because of other parts: make -j1: about 2s slower make -j32: about 0.4s slower If we run to do_install: (PARALLEL_MAKE = "-j32") libtool 2.4.2: $ bitbake xz-native -cinstall && bitbake xz-native -ccleansstate && time bitbake xz-native -cinstall real 0m21.092s user 0m28.292s sys 0m3.932s libtool 2.4.5: $ bitbake xz-native -cinstall && bitbake xz-native -ccleansstate && time bitbake xz-native -cinstall real 0m21.380s user 0m31.140s sys 0m4.068s About 0.3s, slightly different. But when using /bin/bash as CONFIG_SHELL, the new libtool would be much slower: real 0m23.106s user 0m44.044s sys 0m4.280s About 2s slower, for the big package like cairo, it is more slower (about 6s), unfortunately, /bin/bash is most default CONFIG_SHELL for the recipes since configure checks first check bash. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-03libtool: Fix tools path issuesRichard Purdie1
If for example you build on a machine with /bin/grep, then restore that sstate onto a machine with /usr/bin/grep, things will fail. Simply don't bother hardcoding paths. This was lost during the libtool upgrade: http://git.yoctoproject.org/cgit.cgi/poky/diff/meta/recipes-devtools/libtool/libtool/avoid_absolute_paths_for_general_utils.patch?id=d4e1862453b2a4c12400de0f43f08a9871a4de60 since the path to the files changed. This restores the previous behaviour. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-02libtool: 2.4.4 -> 2.4.5Richard Purdie1
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>