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

Submitted by Jason Wessel on Feb. 12, 2013, 7:36 p.m.

Details

Message ID 1360697804-39039-1-git-send-email-jason.wessel@windriver.com
State Accepted
Commit 80d0081d42f579d5ea7fab43bce6f6a54d96934a
Headers show

Commit Message

Jason Wessel Feb. 12, 2013, 7:36 p.m.
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(-)

Patch hide | download patch | download mbox

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

Comments

Richard Purdie Feb. 12, 2013, 9:39 p.m.
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
Mark Hatle Feb. 12, 2013, 9:45 p.m.
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
>
Jason Wessel Feb. 12, 2013, 10:03 p.m.
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.
Richard Purdie Feb. 12, 2013, 10:53 p.m.
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
Khem Raj Feb. 13, 2013, 2:43 a.m.
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
Denys Dmytriyenko Sept. 26, 2013, 10:40 p.m.
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
Richard Purdie Sept. 27, 2013, 9:20 a.m.
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
Richard Purdie Sept. 27, 2013, 10:06 a.m.
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
Denys Dmytriyenko Sept. 27, 2013, 4:49 p.m.
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!