All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Jason Wessel <jason.wessel@windriver.com>
Cc: Openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
Date: Tue, 12 Feb 2013 21:39:07 +0000	[thread overview]
Message-ID: <1360705147.30425.70.camel@ted> (raw)
In-Reply-To: <1360697804-39039-1-git-send-email-jason.wessel@windriver.com>

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@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




  reply	other threads:[~2013-02-12 21:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 19:36 [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED Jason Wessel
2013-02-12 21:39 ` Richard Purdie [this message]
2013-02-12 21:45   ` Mark Hatle
2013-02-12 22:03   ` Jason Wessel
2013-02-12 22:53     ` Richard Purdie
2013-02-13  2:43       ` Khem Raj
2013-09-26 22:40 ` Denys Dmytriyenko
2013-09-27  9:20   ` Richard Purdie
2013-09-27 10:06     ` Richard Purdie
2013-09-27 16:49       ` Denys Dmytriyenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1360705147.30425.70.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=Openembedded-core@lists.openembedded.org \
    --cc=jason.wessel@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.