Patchwork libtool: Add missing DEPENDS on libtool-cross

login
register
mail settings
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

chase maupin - Oct. 2, 2012, 9:30 p.m.
* 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(-)
Richard Purdie - Oct. 4, 2012, 9:21 a.m.
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
chase maupin - Oct. 4, 2012, 12:39 p.m.
> -----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
Richard Purdie - Oct. 4, 2012, 12:58 p.m.
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
chase maupin - Oct. 4, 2012, 1:02 p.m.
> -----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.