libtool-native_2.4.2.bb: Always use /bin/sed for SED

If you never use sstate and always build everything from scratch you
will never see this problem.  However, if you use sstate and build
directories that last a long time eventually you can end up with the
scenario where libtool gets a hard coded path in it for sed, and sed
may not exist.  The reason you don't see this problem to often if you
generally build from scratch is that libtool builds before sed and
will pickup the host's /bin/sed.

The way to reproduce the issue is:

bitbake some_image
bitbake -c cleansstate libtool-native
bitbake sed-native
bitbake libtool-native
bitbake -c clean sed-native
bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE

In my case I used modphp, which doesn't exist in the oe-core. You will
end up with a strange looking error like:

| make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
| /opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool: line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: No such file or directory

The solution is to always use /bin/sed for libtool-native.

(From OE-Core rev: 605e4484840e70c64acddb4aa1a3c9fec4078d9d)

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Jason Wessel 2013-02-12 13:36:44 -06:00 committed by Richard Purdie
parent 4c548f17b0
commit 80d0081d42
1 changed files with 2 additions and 1 deletions

View File

@ -2,12 +2,13 @@ require libtool-${PV}.inc
DEPENDS = ""
PR = "${INC_PR}.0"
PR = "${INC_PR}.1"
SRC_URI += "file://prefix.patch"
inherit native
EXTRA_OECONF = " --with-libtool-sysroot=${STAGING_DIR_NATIVE}"
CACHED_CONFIGUREVARS += "ac_cv_path_SED=/bin/sed"
do_configure_prepend () {
# Remove any existing libtool m4 since old stale versions would break