Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
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.wes...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
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.wes...@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: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
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.wes...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
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.wes...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
On Tue, Feb 12, 2013 at 2:53 PM, Richard Purdie
richard.pur...@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.wes...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
