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

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

[Jason Wessel]

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_configure_prepend () {
 	# Remove any existing libtool m4 since old stale versions would break
-- 
1.7.1

Re: [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@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

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

[Mark Hatle]

On 2/12/13 3:39 PM, Richard Purdie wrote:
> 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"?

We considered this.  The problem w/ using env to call sed is there is a small 
window where the sed-native is being constructed, that we can have a failure.

--Mark

> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

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

[Jason Wessel]

On 02/12/2013 03:39 PM, Richard Purdie wrote:
> 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"?
>

The libtool seems to be in a class of its own with respect to internally hard coding things, so I am inclined to say this is a one off because A) it is libtool and B) it is part of the boot strap. For any other packages I have not observed any kind of problem with the sysroot sed vs host provided sed.

Unfortunately doing ${bindir}/env sed can lead to a fairly rare race where sed can be there an get removed later because it will prefer the sed in the sysroot area because it is in the path first.  I never hit any of these problems until recently while continuing to just randomly build things with the usual stream of updates from the git repository.

If we want libtool-native to use something other than /bin/sed on the host, the bootstrap needs some kind of overhaul to make libtool depend correctly on sed.  Currently we end up with a circular dependency if you try to make libtool-native depend on sed-native.

Jason.

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

[Richard Purdie]

On Tue, 2013-02-12 at 16:03 -0600, Jason Wessel wrote:
> On 02/12/2013 03:39 PM, Richard Purdie wrote:
> > 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"?
> >
> 
> The libtool seems to be in a class of its own with respect to
> internally hard coding things, so I am inclined to say this is a one
> off because A) it is libtool and B) it is part of the boot strap. For
> any other packages I have not observed any kind of problem with the
> sysroot sed vs host provided sed.
> 
> Unfortunately doing ${bindir}/env sed can lead to a fairly rare race
> where sed can be there an get removed later because it will prefer the
> sed in the sysroot area because it is in the path first.  I never hit
> any of these problems until recently while continuing to just randomly
> build things with the usual stream of updates from the git repository.
> 
> If we want libtool-native to use something other than /bin/sed on the
> host, the bootstrap needs some kind of overhaul to make libtool depend
> correctly on sed.  Currently we end up with a circular dependency if
> you try to make libtool-native depend on sed-native.

Does it make sense for sed-native to ever be built? I know we have
issues with some others like tar, bzip/gzip and friends but no issues
with sed afaik?

Cheers,

Richard

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

[Khem Raj]

On Tue, Feb 12, 2013 at 2:53 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2013-02-12 at 16:03 -0600, Jason Wessel wrote:
>> On 02/12/2013 03:39 PM, Richard Purdie wrote:
>> > 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"?
>> >
>>
>> The libtool seems to be in a class of its own with respect to
>> internally hard coding things, so I am inclined to say this is a one
>> off because A) it is libtool and B) it is part of the boot strap. For
>> any other packages I have not observed any kind of problem with the
>> sysroot sed vs host provided sed.
>>
>> Unfortunately doing ${bindir}/env sed can lead to a fairly rare race
>> where sed can be there an get removed later because it will prefer the
>> sed in the sysroot area because it is in the path first.  I never hit
>> any of these problems until recently while continuing to just randomly
>> build things with the usual stream of updates from the git repository.
>>
>> If we want libtool-native to use something other than /bin/sed on the
>> host, the bootstrap needs some kind of overhaul to make libtool depend
>> correctly on sed.  Currently we end up with a circular dependency if
>> you try to make libtool-native depend on sed-native.
>
> Does it make sense for sed-native to ever be built? I know we have
> issues with some others like tar, bzip/gzip and friends but no issues
> with sed afaik?
>

we could if we get rid of it from following

meta/classes/populate_sdk_base.bbclass:SDK_DEPENDS =
"virtual/fakeroot-native sed-native"
meta/recipes-core/meta/external-python-tarball.bb:DEPENDS =
"opkg-native opkg-utils-native virtual/fakeroot-native sed-native"
meta/recipes-devtools/libtool/libtool-2.4.2.inc:# Don't want paths to
sed-native (or anything else) encoded
meta/recipes-gnome/packagegroups/packagegroup-toolset-native.bb:    sed-native \




> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

[Denys Dmytriyenko]

On Tue, Feb 12, 2013 at 01:36:44PM -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

Sorry for bringing up this old thread. I'm seeing these and similar errors now 
(nothing really changed in my setup, but some race got them exposed).

I do see that the proposed patch got merged all the way back in February. But 
looks like it wasn't enough.

I've just seen this error about missing sysroots/x86_64-linux//bin/sed coming 
from nativesdk-gettext compilation while calling i686-linux-libtool, i.e. the 
nativesdk version of libtool. Should be easy to duplicate the below patch for 
libtool from native to nativesdk recipe.

And another error was from sysroots/x86_64-linux/usr/bin/opkg-build during 
do_package_write of some other package. Should opkg-utils-native be patched 
the same?

Denys


> 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_configure_prepend () {
>  	# Remove any existing libtool m4 since old stale versions would break
> -- 
> 1.7.1
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

[Richard Purdie]

On Thu, 2013-09-26 at 18:40 -0400, Denys Dmytriyenko wrote:
> On Tue, Feb 12, 2013 at 01:36:44PM -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
> 
> Sorry for bringing up this old thread. I'm seeing these and similar errors now 
> (nothing really changed in my setup, but some race got them exposed).
> 
> I do see that the proposed patch got merged all the way back in February. But 
> looks like it wasn't enough.
> 
> I've just seen this error about missing sysroots/x86_64-linux//bin/sed coming 
> from nativesdk-gettext compilation while calling i686-linux-libtool, i.e. the 
> nativesdk version of libtool. Should be easy to duplicate the below patch for 
> libtool from native to nativesdk recipe.
> 
> And another error was from sysroots/x86_64-linux/usr/bin/opkg-build during 
> do_package_write of some other package. Should opkg-utils-native be patched 
> the same?

Was this in master with
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=32edeb391f2107bb66b361cdcd4b8d4447731c33 applied?

Cheers,

Richard

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

[Richard Purdie]

On Fri, 2013-09-27 at 10:20 +0100, Richard Purdie wrote:
> On Thu, 2013-09-26 at 18:40 -0400, Denys Dmytriyenko wrote:
> > On Tue, Feb 12, 2013 at 01:36:44PM -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
> > 
> > Sorry for bringing up this old thread. I'm seeing these and similar errors now 
> > (nothing really changed in my setup, but some race got them exposed).
> > 
> > I do see that the proposed patch got merged all the way back in February. But 
> > looks like it wasn't enough.
> > 
> > I've just seen this error about missing sysroots/x86_64-linux//bin/sed coming 
> > from nativesdk-gettext compilation while calling i686-linux-libtool, i.e. the 
> > nativesdk version of libtool. Should be easy to duplicate the below patch for 
> > libtool from native to nativesdk recipe.
> > 
> > And another error was from sysroots/x86_64-linux/usr/bin/opkg-build during 
> > do_package_write of some other package. Should opkg-utils-native be patched 
> > the same?
> 
> Was this in master with
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=32edeb391f2107bb66b361cdcd4b8d4447731c33 applied?

To answer my own question, the above introduced a bug since I'd
forgotten native doesn't use the site files. It probably should use at
least a minimal one so I've sent out a patch for that.

Cheers,

Richard

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

[Denys Dmytriyenko]

On Fri, Sep 27, 2013 at 11:06:42AM +0100, Richard Purdie wrote:
> On Fri, 2013-09-27 at 10:20 +0100, Richard Purdie wrote:
> > On Thu, 2013-09-26 at 18:40 -0400, Denys Dmytriyenko wrote:
> > > On Tue, Feb 12, 2013 at 01:36:44PM -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
> > > 
> > > Sorry for bringing up this old thread. I'm seeing these and similar errors now 
> > > (nothing really changed in my setup, but some race got them exposed).
> > > 
> > > I do see that the proposed patch got merged all the way back in February. But 
> > > looks like it wasn't enough.
> > > 
> > > I've just seen this error about missing sysroots/x86_64-linux//bin/sed coming 
> > > from nativesdk-gettext compilation while calling i686-linux-libtool, i.e. the 
> > > nativesdk version of libtool. Should be easy to duplicate the below patch for 
> > > libtool from native to nativesdk recipe.
> > > 
> > > And another error was from sysroots/x86_64-linux/usr/bin/opkg-build during 
> > > do_package_write of some other package. Should opkg-utils-native be patched 
> > > the same?
> > 
> > Was this in master with
> > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=32edeb391f2107bb66b361cdcd4b8d4447731c33 applied?
> 
> To answer my own question, the above introduced a bug since I'd
> forgotten native doesn't use the site files. It probably should use at
> least a minimal one so I've sent out a patch for that.

Richard,

I was getting that on dylan and master, but the above patch was not in yet. 
I'll give this one and the new native site config patch a try. Thanks!

-- 
Denys