The libltdl libraries are put in libltdl-* packages, but libltdl.la
is packaged in libtool-dev. This change puts libltdl.la in libltdl-dev
package instead of libtool-dev.

Signed-off-by: Li Zhou <li.zhou@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Drop patch merged upstream.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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>

This reverts commit 1f53edeaf9ea59dd55459a6d5a93829fb4983839.

There is a better fix on upstream, will backport it.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>

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>

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>

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>

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

* Upgrade:
  - libtool-native
  - libtool-cross
  - nativesdk-libtool
  - libtool

* Remove 2 patches:
  - respect-fstack-protector.patch: already in the new source.
  - avoid_absolute_paths_for_general_utils.patch: no general.m4sh any
    more.
  - Use inline-source to install libtoolize.

* Update other patches

* The LIC_FILES_CHKSUM is changed because of the indent, the contents
  are the same.

* The libtool config files are put in libtool/build-aux now, it was
  libtool/config in the past.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>

Resulted libtool contains references about paths from the build host

Below variables contains hard coded build paths from the host:
LTCC=
lt_sysroot=
sys_lib_search_path_spec=
LD=
CC=
compiler_lib_search_dirs=
predep_objects=
postdep_objects=
compiler_lib_search_path=

Signed-off-by: Shiqun Lin <Shiqun.Lin@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>