| Submitter | Jason Wessel |
|---|---|
| Date | Feb. 12, 2013, 7:36 p.m. |
| Message ID | <1360697804-39039-1-git-send-email-jason.wessel@windriver.com> |
| Download | mbox | patch |
| Permalink | /patch/44541/ |
| State | Accepted |
| Commit | 605e4484840e70c64acddb4aa1a3c9fec4078d9d |
| Headers | show |
Comments
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
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 >
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.
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
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
Patch
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
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(-)