[OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED

[Richard Purdie]

On Tue, 2013-02-12 at 13:36 -0600, Jason Wessel wrote:
> 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.
> 
> Signed-off-by: Jason Wessel <jason.wessel at windriver.com>
> ---
>  .../libtool/libtool-native_2.4.2.bb                |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
> index f12e6a1..18188ef 100644
> --- a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
> +++ b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
> @@ -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 we have to set a path for it? Can't we rely on PATH being sane? I'm
wondering if we should actually set this in the core site files.
Hardcoding a path to utilities never usually ends well and this is just
the tip of an iceberg.

If we have to use a path, "${bindir}/env sed"?

Cheers,

Richard