| Submitter | chase maupin |
|---|---|
| Date | Oct. 2, 2012, 9:30 p.m. |
| Message ID | <1349213439-14199-1-git-send-email-Chase.Maupin@ti.com> |
| Download | mbox | patch |
| Permalink | /patch/37633/ |
| State | New |
| Headers | show |
Comments
On Tue, 2012-10-02 at 16:30 -0500, Chase Maupin wrote: > * When building with 24 bitbake threads on my system I observed > errors like the following: > | configure.ac:199: error: LT_LANG: unsupported language: "Go" > | <tmpdir>/work/armv7a-vfp-neon-oe-linux-gnueabi/libtool-2.4.2-r3.0/libtool-2.4.2/aclocal-copy/libtool.m4:768: LT_LANG is expanded from... > | configure.ac:199: the top level > | autom4te: m4 failed with exit status: 1 > * This could be found by doing a clean build. If a build had > already been performed then often just cleaning the libtool > package and rebuilding it would resolve the issue. > * Adding a DEPENDS on libtool-cross resolves this issue with a > clean build. > * Bump the PR So how do I reproduce this bug? In theory I'd just run "bitbake libtool" in a clean build directory? I've tried that with master and it all works? :/ Cheers, Richard
> -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] On > Behalf Of Richard Purdie > Sent: Thursday, October 04, 2012 4:21 AM > To: Maupin, Chase > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on > libtool-cross > > On Tue, 2012-10-02 at 16:30 -0500, Chase Maupin wrote: > > * When building with 24 bitbake threads on my system I observed > > errors like the following: > > | configure.ac:199: error: LT_LANG: unsupported language: > "Go" > > | <tmpdir>/work/armv7a-vfp-neon-oe-linux-gnueabi/libtool- > 2.4.2-r3.0/libtool-2.4.2/aclocal-copy/libtool.m4:768: LT_LANG is > expanded from... > > | configure.ac:199: the top level > > | autom4te: m4 failed with exit status: 1 > > * This could be found by doing a clean build. If a build had > > already been performed then often just cleaning the libtool > > package and rebuilding it would resolve the issue. > > * Adding a DEPENDS on libtool-cross resolves this issue with a > > clean build. > > * Bump the PR > > So how do I reproduce this bug? In theory I'd just run "bitbake > libtool" > in a clean build directory? > > I've tried that with master and it all works? :/ Richard, I was able to reproduce this consistently on my build server which has 24 cores running at 3.5 GHz. I was using: BB_NUMBER_THREADS = "24" And PARALLEL_MAKE = "-j 24" I can try a build reducing the number of threads and see if the issue goes away as this might be a difference between our builds. Can you tell me what you are using? It seemed like a race condition because after I got the error I was able to do a -c cleanall of libtool and kick off the build again once libtool-cross was built and it would pass. Likewise I did: bitbake libtool-cross bitbake libtool and that would work but just bitbake libtool would fail. > > Cheers, > > Richard > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded- > core
On Thu, 2012-10-04 at 12:39 +0000, Maupin, Chase wrote: > I was able to reproduce this consistently on my build server which has > 24 cores running at 3.5 GHz. I was using: > > BB_NUMBER_THREADS = "24" > > And > > PARALLEL_MAKE = "-j 24" > > I can try a build reducing the number of threads and see if the issue > goes away as this might be a difference between our builds. Can you > tell me what you are using? I tested this with 48/48 in master. > It seemed like a race condition because after I got the error I was > able to do a -c cleanall of libtool and kick off the build again once > libtool-cross was built and it would pass. Likewise I did: > > bitbake libtool-cross > bitbake libtool > > and that would work but just > > bitbake libtool > > would fail. "bitbake libtool" works here quite consistently. I therefore don't want to add this dependency until we figure out exactly what is racing against what or have a better understanding of why this is failing. Something doesn't seem right as if your premise of a missing dependency is correct, the above wouldn't work. Cheers, Richard
> -----Original Message----- > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org] > Sent: Thursday, October 04, 2012 7:58 AM > To: Maupin, Chase > Cc: openembedded-core@lists.openembedded.org > Subject: RE: [OE-core] [PATCH] libtool: Add missing DEPENDS on > libtool-cross > > On Thu, 2012-10-04 at 12:39 +0000, Maupin, Chase wrote: > > I was able to reproduce this consistently on my build server > which has > > 24 cores running at 3.5 GHz. I was using: > > > > BB_NUMBER_THREADS = "24" > > > > And > > > > PARALLEL_MAKE = "-j 24" > > > > I can try a build reducing the number of threads and see if the > issue > > goes away as this might be a difference between our builds. > Can you > > tell me what you are using? > > I tested this with 48/48 in master. > > > It seemed like a race condition because after I got the error I > was > > able to do a -c cleanall of libtool and kick off the build > again once > > libtool-cross was built and it would pass. Likewise I did: > > > > bitbake libtool-cross > > bitbake libtool > > > > and that would work but just > > > > bitbake libtool > > > > would fail. > > "bitbake libtool" works here quite consistently. I therefore > don't want > to add this dependency until we figure out exactly what is racing > against what or have a better understanding of why this is > failing. > Something doesn't seem right as if your premise of a missing > dependency > is correct, the above wouldn't work. Understood. Let me look closer. My build setup is an Ubuntu 10.04 system and I'm using an external Arago toolchain as well. On my setup I can consistently cause this to fail even with a lower number of threads. So perhaps the issue is not the libtool-cross dependency, but that libtool-cross itself forces something else to be built first. Thanks for the information on your setup and confirmation that you do not see this issue. > > Cheers, > > Richard > >
Patch
diff --git a/meta/recipes-devtools/libtool/libtool_2.4.2.bb b/meta/recipes-devtools/libtool/libtool_2.4.2.bb index a2eb4ea..f376b67 100644 --- a/meta/recipes-devtools/libtool/libtool_2.4.2.bb +++ b/meta/recipes-devtools/libtool/libtool_2.4.2.bb @@ -1,6 +1,8 @@ require libtool-${PV}.inc -PR = "${INC_PR}.0" +PR = "${INC_PR}.1" + +DEPENDS += "libtool-cross" # # We want the results of libtool-cross preserved - don't stage anything ourselves.
* When building with 24 bitbake threads on my system I observed errors like the following: | configure.ac:199: error: LT_LANG: unsupported language: "Go" | <tmpdir>/work/armv7a-vfp-neon-oe-linux-gnueabi/libtool-2.4.2-r3.0/libtool-2.4.2/aclocal-copy/libtool.m4:768: LT_LANG is expanded from... | configure.ac:199: the top level | autom4te: m4 failed with exit status: 1 * This could be found by doing a clean build. If a build had already been performed then often just cleaning the libtool package and rebuilding it would resolve the issue. * Adding a DEPENDS on libtool-cross resolves this issue with a clean build. * Bump the PR Signed-off-by: Chase Maupin <Chase.Maupin@ti.com> --- meta/recipes-devtools/libtool/libtool_2.4.2.bb | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)