80d0081d42
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> |
||
|---|---|---|
| .. | ||
| libtool | ||
| libtool-2.4.2.inc | ||
| libtool-cross_2.4.2.bb | ||
| libtool-native_2.4.2.bb | ||
| libtool-nativesdk_2.4.2.bb | ||
| libtool_2.4.2.bb | ||