generic-poky/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
Jason Wessel 80d0081d42 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>
2013-02-13 16:52:30 +00:00

26 lines
564 B
BlitzBasic

require libtool-${PV}.inc
DEPENDS = ""
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
# any upgrade
rm -f ${STAGING_DATADIR}/aclocal/libtool.m4
rm -f ${STAGING_DATADIR}/aclocal/lt*.m4
}
do_install () {
autotools_do_install
install -d ${D}${bindir}/
install -m 0755 ${HOST_SYS}-libtool ${D}${bindir}/${HOST_SYS}-libtool
}