libtool-native_2.4.2.bb: Always use /bin/sed for SED
authorJason Wessel <jason.wessel@windriver.com>
Tue, 12 Feb 2013 19:36:44 +0000 (13:36 -0600)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Wed, 13 Feb 2013 16:52:30 +0000 (16:52 +0000)
commit9c16bd3883f2cbf87bce41bc5acf4c861ff3c549
treef3d806940ba7297cad474f22cddd400cbf830b49
parent3f6ae86c99be808050bf9be45c1c2f98a24378cd
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>
meta/recipes-devtools/libtool/libtool-native_2.4.2.bb