[PATCH] libtool: Add missing DEPENDS on libtool-cross

[PATCH] libtool: Add missing DEPENDS on libtool-cross

[Chase Maupin]

* 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(-)

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.
-- 
1.7.0.4

Re: [PATCH] libtool: Add missing DEPENDS on libtool-cross

[Richard Purdie]

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

Re: [PATCH] libtool: Add missing DEPENDS on libtool-cross

[Maupin, Chase]

> -----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

Re: [PATCH] libtool: Add missing DEPENDS on libtool-cross

[Richard Purdie]

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

Re: [PATCH] libtool: Add missing DEPENDS on libtool-cross

[Maupin, Chase]

> -----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
> 
> 

Re: [PATCH] libtool: Add missing DEPENDS on libtool-cross

[Maupin, Chase]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On
> Behalf Of Maupin, Chase
> Sent: Thursday, October 04, 2012 8:02 AM
> To: Richard Purdie
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on
> libtool-cross
> 
> > -----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.

I tried the following to help narrow this down.  Please let me know if there is something else I could try to help narrow the issue.  I ran:

bitbake -c cleanall libtool
bitbake libtool

Each time it failed I would get a list of the contents of the work directory and the stamps directory.  My goal here was to be able to find what changed between a pass and a fail.  I kept running the test above until I had a consistent failure, and there were no new packages being added into my work directory and no new stamps being created.  Basically this told me that all the packages that were going to be built from doing "bitbake libtool" were built and that the only package being built was libtool itself.

I then changed my build steps to do:

bitbake -c cleanall libtool
bitbake libtool-cross
bitbake libtool

This passed on the first run.  I captured the same work directory contents and stamps contents and then did a diff to see what had changed between these builds.  The diffs were:

For Stamps diff libtool-failed-stamps libtool-passed-stamps
-----------------------------------------------------------
/arago-tmp-eglibc/stamps$ diff -burpN libtool-failed-stamps libtool-passed-stamps 
--- libtool-failed-stamps	2012-10-04 09:11:27.909881710 -0500
+++ libtool-passed-stamps	2012-10-04 09:14:33.997328844 -0500
@@ -23,18 +23,56 @@ external-arago-toolchain-1.0-r2.do_popul
 external-arago-toolchain-1.0-r2.do_populate_sysroot.sigdata.bccac35b2b6fecd3cbec49ccc208c6a9
 external-arago-toolchain-1.0-r2.do_unpack
 external-arago-toolchain-1.0-r2.do_unpack.sigdata.14d8090b51a447ceb4ccf44941781e47
+libtool-2.4.2-r3.0.do_build
 libtool-2.4.2-r3.0.do_cleansstate
 libtool-2.4.2-r3.0.do_cleansstate.sigdata.e2a5d5c89e3be41823e835c18b50dfa3
+libtool-2.4.2-r3.0.do_compile
+libtool-2.4.2-r3.0.do_compile.sigdata.ea5125c6ecc524aed598dba3b731d92d
+libtool-2.4.2-r3.0.do_configure
+libtool-2.4.2-r3.0.do_configure.sigdata.2e462cacc7c699c75bce74bb7dcf55f4
 libtool-2.4.2-r3.0.do_create_srcipk
 libtool-2.4.2-r3.0.do_create_srcipk.sigdata.caa56f6b8b195ff4e6a063f1288c5f86
 libtool-2.4.2-r3.0.do_fetch
 libtool-2.4.2-r3.0.do_fetch.sigdata.0ccdbfe0aace02237038ae0203de9060
+libtool-2.4.2-r3.0.do_install
+libtool-2.4.2-r3.0.do_install.sigdata.9ad203ae762fe0556e7a991ab8a7707c
+libtool-2.4.2-r3.0.do_package.am335x-evm
+libtool-2.4.2-r3.0.do_package.sigdata.ffb4b811e7643d5f37afbcffef84f5e8
+libtool-2.4.2-r3.0.do_package_write
+libtool-2.4.2-r3.0.do_package_write_ipk
+libtool-2.4.2-r3.0.do_package_write_ipk.sigdata.eb16601f7f4f1afbfabc8542fea3af30
 libtool-2.4.2-r3.0.do_patch
 libtool-2.4.2-r3.0.do_patch.sigdata.7d028f6dc6a1bdf32aadc29a6444bebc
 libtool-2.4.2-r3.0.do_populate_lic
 libtool-2.4.2-r3.0.do_populate_lic.sigdata.ebd50cceb0903e1b277ad6f533055373
+libtool-2.4.2-r3.0.do_populate_sysroot.am335x-evm
+libtool-2.4.2-r3.0.do_populate_sysroot.sigdata.43f8d1df81e38dacd301eed5599094f1
 libtool-2.4.2-r3.0.do_unpack
 libtool-2.4.2-r3.0.do_unpack.sigdata.f97c2643ec8f5752b2537f305a45ca7e
+libtool-cross-2.4.2-r3.1.do_build
+libtool-cross-2.4.2-r3.1.do_compile
+libtool-cross-2.4.2-r3.1.do_compile.sigdata.c04f058e41aabe9001f0b82764d51d24
+libtool-cross-2.4.2-r3.1.do_configure
+libtool-cross-2.4.2-r3.1.do_configure.sigdata.b37940faf1adfcc783e7a66eff351d4b
+libtool-cross-2.4.2-r3.1.do_create_srcipk
+libtool-cross-2.4.2-r3.1.do_create_srcipk.sigdata.37082cdfd6eb100923aab805101fe221
+libtool-cross-2.4.2-r3.1.do_fetch
+libtool-cross-2.4.2-r3.1.do_fetch.sigdata.79da02e9de369c7964c9b54e291088d5
+libtool-cross-2.4.2-r3.1.do_install
+libtool-cross-2.4.2-r3.1.do_install.sigdata.607177b917d48c411c6c2fbaf475867b
+libtool-cross-2.4.2-r3.1.do_package.am335x-evm
+libtool-cross-2.4.2-r3.1.do_package.sigdata.4f0eb910d74ff36b564968e09a8e15f2
+libtool-cross-2.4.2-r3.1.do_package_write
+libtool-cross-2.4.2-r3.1.do_package_write_ipk
+libtool-cross-2.4.2-r3.1.do_package_write_ipk.sigdata.0cc36358a4c5dee1f612fe3a90c60b1a
+libtool-cross-2.4.2-r3.1.do_patch
+libtool-cross-2.4.2-r3.1.do_patch.sigdata.a319c3ae77229a7558409abc179ea99d
+libtool-cross-2.4.2-r3.1.do_populate_lic
+libtool-cross-2.4.2-r3.1.do_populate_lic.sigdata.82a19386b4380a0077d2b55f8934851a
+libtool-cross-2.4.2-r3.1.do_populate_sysroot.am335x-evm
+libtool-cross-2.4.2-r3.1.do_populate_sysroot.sigdata.8c61b5566945f9a439faa916d70a9fd0
+libtool-cross-2.4.2-r3.1.do_unpack
+libtool-cross-2.4.2-r3.1.do_unpack.sigdata.322a15e21f6df957f5ba116da19d5585
 linux-libc-headers-3.2-r1.do_compile
 linux-libc-headers-3.2-r1.do_compile.sigdata.6047c862356fa8f3a56269daf2cde26b
 linux-libc-headers-3.2-r1.do_configure

Notice that the only stamps for steps done between a passing and failing build are for the libtool-cross, as well as the steps after the do_configure step of libtool since it passed this time.

The work directory difference was
-----------------------------------
--- libtool-failed-work	2012-10-04 09:17:50.137609986 -0500
+++ libtool-passed-work	2012-10-04 09:17:50.137609986 -0500
@@ -39,4 +39,5 @@ unifdef-native-2.6.18+git-r0
 zlib-native-1.2.6-r1
 external-arago-toolchain-1.0-r2
 libtool-2.4.2-r3.0
+libtool-cross-2.4.2-r3.1
 linux-libc-headers-3.2-r1

So the only new package I saw show-up in my work directory was libtool-cross.

Does anyone have any other suggestions of what to look at since my testing is showing that adding libtool-cross into the build before libtool allows the build to pass.  I'll try going back to the internal toolchain instead of my external toolchain as another test to run but any other ideas would be appreciated.  Is my approach above even valid?

> 
> >
> > Cheers,
> >
> > Richard
> >
> >
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> core

Re: [PATCH] libtool: Add missing DEPENDS on libtool-cross

[Richard Purdie]

On Thu, 2012-10-04 at 14:06 +0000, Maupin, Chase wrote:
> I tried the following to help narrow this down.  Please let me know if there is something else I could try to help narrow the issue.  I ran:
> 
> bitbake -c cleanall libtool
> bitbake libtool
> 
> Each time it failed I would get a list of the contents of the work directory and the stamps directory.  My goal here was to be able to find what changed between a pass and a fail.  I kept running the test above until I had a consistent failure, and there were no new packages being added into my work directory and no new stamps being created.  Basically this told me that all the packages that were going to be built from doing "bitbake libtool" were built and that the only package being built was libtool itself.
> 
> I then changed my build steps to do:
> 
> bitbake -c cleanall libtool
> bitbake libtool-cross
> bitbake libtool
> 
> This passed on the first run.  I captured the same work directory contents and stamps contents and then did a diff to see what had changed between these builds.  The diffs were:
> 
> For Stamps diff libtool-failed-stamps libtool-passed-stamps
> -----------------------------------------------------------
> /arago-tmp-eglibc/stamps$ diff -burpN libtool-failed-stamps libtool-passed-stamps 
> --- libtool-failed-stamps	2012-10-04 09:11:27.909881710 -0500
> +++ libtool-passed-stamps	2012-10-04 09:14:33.997328844 -0500
> @@ -23,18 +23,56 @@ external-arago-toolchain-1.0-r2.do_popul
>  external-arago-toolchain-1.0-r2.do_populate_sysroot.sigdata.bccac35b2b6fecd3cbec49ccc208c6a9
>  external-arago-toolchain-1.0-r2.do_unpack
>  external-arago-toolchain-1.0-r2.do_unpack.sigdata.14d8090b51a447ceb4ccf44941781e47
> +libtool-2.4.2-r3.0.do_build
>  libtool-2.4.2-r3.0.do_cleansstate
>  libtool-2.4.2-r3.0.do_cleansstate.sigdata.e2a5d5c89e3be41823e835c18b50dfa3
> +libtool-2.4.2-r3.0.do_compile
> +libtool-2.4.2-r3.0.do_compile.sigdata.ea5125c6ecc524aed598dba3b731d92d
> +libtool-2.4.2-r3.0.do_configure
> +libtool-2.4.2-r3.0.do_configure.sigdata.2e462cacc7c699c75bce74bb7dcf55f4
>  libtool-2.4.2-r3.0.do_create_srcipk
>  libtool-2.4.2-r3.0.do_create_srcipk.sigdata.caa56f6b8b195ff4e6a063f1288c5f86
>  libtool-2.4.2-r3.0.do_fetch
>  libtool-2.4.2-r3.0.do_fetch.sigdata.0ccdbfe0aace02237038ae0203de9060
> +libtool-2.4.2-r3.0.do_install
> +libtool-2.4.2-r3.0.do_install.sigdata.9ad203ae762fe0556e7a991ab8a7707c
> +libtool-2.4.2-r3.0.do_package.am335x-evm
> +libtool-2.4.2-r3.0.do_package.sigdata.ffb4b811e7643d5f37afbcffef84f5e8
> +libtool-2.4.2-r3.0.do_package_write
> +libtool-2.4.2-r3.0.do_package_write_ipk
> +libtool-2.4.2-r3.0.do_package_write_ipk.sigdata.eb16601f7f4f1afbfabc8542fea3af30
>  libtool-2.4.2-r3.0.do_patch
>  libtool-2.4.2-r3.0.do_patch.sigdata.7d028f6dc6a1bdf32aadc29a6444bebc
>  libtool-2.4.2-r3.0.do_populate_lic
>  libtool-2.4.2-r3.0.do_populate_lic.sigdata.ebd50cceb0903e1b277ad6f533055373
> +libtool-2.4.2-r3.0.do_populate_sysroot.am335x-evm
> +libtool-2.4.2-r3.0.do_populate_sysroot.sigdata.43f8d1df81e38dacd301eed5599094f1
>  libtool-2.4.2-r3.0.do_unpack
>  libtool-2.4.2-r3.0.do_unpack.sigdata.f97c2643ec8f5752b2537f305a45ca7e
> +libtool-cross-2.4.2-r3.1.do_build
> +libtool-cross-2.4.2-r3.1.do_compile
> +libtool-cross-2.4.2-r3.1.do_compile.sigdata.c04f058e41aabe9001f0b82764d51d24
> +libtool-cross-2.4.2-r3.1.do_configure
> +libtool-cross-2.4.2-r3.1.do_configure.sigdata.b37940faf1adfcc783e7a66eff351d4b
> +libtool-cross-2.4.2-r3.1.do_create_srcipk
> +libtool-cross-2.4.2-r3.1.do_create_srcipk.sigdata.37082cdfd6eb100923aab805101fe221
> +libtool-cross-2.4.2-r3.1.do_fetch
> +libtool-cross-2.4.2-r3.1.do_fetch.sigdata.79da02e9de369c7964c9b54e291088d5
> +libtool-cross-2.4.2-r3.1.do_install
> +libtool-cross-2.4.2-r3.1.do_install.sigdata.607177b917d48c411c6c2fbaf475867b
> +libtool-cross-2.4.2-r3.1.do_package.am335x-evm
> +libtool-cross-2.4.2-r3.1.do_package.sigdata.4f0eb910d74ff36b564968e09a8e15f2
> +libtool-cross-2.4.2-r3.1.do_package_write
> +libtool-cross-2.4.2-r3.1.do_package_write_ipk
> +libtool-cross-2.4.2-r3.1.do_package_write_ipk.sigdata.0cc36358a4c5dee1f612fe3a90c60b1a
> +libtool-cross-2.4.2-r3.1.do_patch
> +libtool-cross-2.4.2-r3.1.do_patch.sigdata.a319c3ae77229a7558409abc179ea99d
> +libtool-cross-2.4.2-r3.1.do_populate_lic
> +libtool-cross-2.4.2-r3.1.do_populate_lic.sigdata.82a19386b4380a0077d2b55f8934851a
> +libtool-cross-2.4.2-r3.1.do_populate_sysroot.am335x-evm
> +libtool-cross-2.4.2-r3.1.do_populate_sysroot.sigdata.8c61b5566945f9a439faa916d70a9fd0
> +libtool-cross-2.4.2-r3.1.do_unpack
> +libtool-cross-2.4.2-r3.1.do_unpack.sigdata.322a15e21f6df957f5ba116da19d5585
>  linux-libc-headers-3.2-r1.do_compile
>  linux-libc-headers-3.2-r1.do_compile.sigdata.6047c862356fa8f3a56269daf2cde26b
>  linux-libc-headers-3.2-r1.do_configure
> 
> Notice that the only stamps for steps done between a passing and failing build are for the libtool-cross, as well as the steps after the do_configure step of libtool since it passed this time.
> 
> The work directory difference was
> -----------------------------------
> --- libtool-failed-work	2012-10-04 09:17:50.137609986 -0500
> +++ libtool-passed-work	2012-10-04 09:17:50.137609986 -0500
> @@ -39,4 +39,5 @@ unifdef-native-2.6.18+git-r0
>  zlib-native-1.2.6-r1
>  external-arago-toolchain-1.0-r2
>  libtool-2.4.2-r3.0
> +libtool-cross-2.4.2-r3.1
>  linux-libc-headers-3.2-r1
> 
> So the only new package I saw show-up in my work directory was libtool-cross.
> 
> Does anyone have any other suggestions of what to look at since my
> testing is showing that adding libtool-cross into the build before
> libtool allows the build to pass.  I'll try going back to the internal
> toolchain instead of my external toolchain as another test to run but
> any other ideas would be appreciated.  Is my approach above even
> valid?

A list of file differences in the sysroots directory would help here.
Given the above, this amounts to the contents of the libtool-cross
package. Are you able to reproduce this with master or is this denzil
based?

Cheers,

Richard

Re: [PATCH] libtool: Add missing DEPENDS on libtool-cross

[Maupin, Chase]

> -----Original Message-----
> From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> Sent: Thursday, October 04, 2012 9:30 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 14:06 +0000, Maupin, Chase wrote:
> > I tried the following to help narrow this down.  Please let me
> know if there is something else I could try to help narrow the
> issue.  I ran:
> >
> > bitbake -c cleanall libtool
> > bitbake libtool
> >
> > Each time it failed I would get a list of the contents of the
> work directory and the stamps directory.  My goal here was to be
> able to find what changed between a pass and a fail.  I kept
> running the test above until I had a consistent failure, and
> there were no new packages being added into my work directory and
> no new stamps being created.  Basically this told me that all the
> packages that were going to be built from doing "bitbake libtool"
> were built and that the only package being built was libtool
> itself.
> >
> > I then changed my build steps to do:
> >
> > bitbake -c cleanall libtool
> > bitbake libtool-cross
> > bitbake libtool
> >
> > This passed on the first run.  I captured the same work
> directory contents and stamps contents and then did a diff to see
> what had changed between these builds.  The diffs were:
> >
> > For Stamps diff libtool-failed-stamps libtool-passed-stamps
> > -----------------------------------------------------------
> > /arago-tmp-eglibc/stamps$ diff -burpN libtool-failed-stamps
> libtool-passed-stamps
> > --- libtool-failed-stamps	2012-10-04 09:11:27.909881710 -0500
> > +++ libtool-passed-stamps	2012-10-04 09:14:33.997328844 -0500
> > @@ -23,18 +23,56 @@ external-arago-toolchain-1.0-r2.do_popul
> >  external-arago-toolchain-1.0-
> r2.do_populate_sysroot.sigdata.bccac35b2b6fecd3cbec49ccc208c6a9
> >  external-arago-toolchain-1.0-r2.do_unpack
> >  external-arago-toolchain-1.0-
> r2.do_unpack.sigdata.14d8090b51a447ceb4ccf44941781e47
> > +libtool-2.4.2-r3.0.do_build
> >  libtool-2.4.2-r3.0.do_cleansstate
> >  libtool-2.4.2-
> r3.0.do_cleansstate.sigdata.e2a5d5c89e3be41823e835c18b50dfa3
> > +libtool-2.4.2-r3.0.do_compile
> > +libtool-2.4.2-
> r3.0.do_compile.sigdata.ea5125c6ecc524aed598dba3b731d92d
> > +libtool-2.4.2-r3.0.do_configure
> > +libtool-2.4.2-
> r3.0.do_configure.sigdata.2e462cacc7c699c75bce74bb7dcf55f4
> >  libtool-2.4.2-r3.0.do_create_srcipk
> >  libtool-2.4.2-
> r3.0.do_create_srcipk.sigdata.caa56f6b8b195ff4e6a063f1288c5f86
> >  libtool-2.4.2-r3.0.do_fetch
> >  libtool-2.4.2-
> r3.0.do_fetch.sigdata.0ccdbfe0aace02237038ae0203de9060
> > +libtool-2.4.2-r3.0.do_install
> > +libtool-2.4.2-
> r3.0.do_install.sigdata.9ad203ae762fe0556e7a991ab8a7707c
> > +libtool-2.4.2-r3.0.do_package.am335x-evm
> > +libtool-2.4.2-
> r3.0.do_package.sigdata.ffb4b811e7643d5f37afbcffef84f5e8
> > +libtool-2.4.2-r3.0.do_package_write
> > +libtool-2.4.2-r3.0.do_package_write_ipk
> > +libtool-2.4.2-
> r3.0.do_package_write_ipk.sigdata.eb16601f7f4f1afbfabc8542fea3af3
> 0
> >  libtool-2.4.2-r3.0.do_patch
> >  libtool-2.4.2-
> r3.0.do_patch.sigdata.7d028f6dc6a1bdf32aadc29a6444bebc
> >  libtool-2.4.2-r3.0.do_populate_lic
> >  libtool-2.4.2-
> r3.0.do_populate_lic.sigdata.ebd50cceb0903e1b277ad6f533055373
> > +libtool-2.4.2-r3.0.do_populate_sysroot.am335x-evm
> > +libtool-2.4.2-
> r3.0.do_populate_sysroot.sigdata.43f8d1df81e38dacd301eed5599094f1
> >  libtool-2.4.2-r3.0.do_unpack
> >  libtool-2.4.2-
> r3.0.do_unpack.sigdata.f97c2643ec8f5752b2537f305a45ca7e
> > +libtool-cross-2.4.2-r3.1.do_build
> > +libtool-cross-2.4.2-r3.1.do_compile
> > +libtool-cross-2.4.2-
> r3.1.do_compile.sigdata.c04f058e41aabe9001f0b82764d51d24
> > +libtool-cross-2.4.2-r3.1.do_configure
> > +libtool-cross-2.4.2-
> r3.1.do_configure.sigdata.b37940faf1adfcc783e7a66eff351d4b
> > +libtool-cross-2.4.2-r3.1.do_create_srcipk
> > +libtool-cross-2.4.2-
> r3.1.do_create_srcipk.sigdata.37082cdfd6eb100923aab805101fe221
> > +libtool-cross-2.4.2-r3.1.do_fetch
> > +libtool-cross-2.4.2-
> r3.1.do_fetch.sigdata.79da02e9de369c7964c9b54e291088d5
> > +libtool-cross-2.4.2-r3.1.do_install
> > +libtool-cross-2.4.2-
> r3.1.do_install.sigdata.607177b917d48c411c6c2fbaf475867b
> > +libtool-cross-2.4.2-r3.1.do_package.am335x-evm
> > +libtool-cross-2.4.2-
> r3.1.do_package.sigdata.4f0eb910d74ff36b564968e09a8e15f2
> > +libtool-cross-2.4.2-r3.1.do_package_write
> > +libtool-cross-2.4.2-r3.1.do_package_write_ipk
> > +libtool-cross-2.4.2-
> r3.1.do_package_write_ipk.sigdata.0cc36358a4c5dee1f612fe3a90c60b1
> a
> > +libtool-cross-2.4.2-r3.1.do_patch
> > +libtool-cross-2.4.2-
> r3.1.do_patch.sigdata.a319c3ae77229a7558409abc179ea99d
> > +libtool-cross-2.4.2-r3.1.do_populate_lic
> > +libtool-cross-2.4.2-
> r3.1.do_populate_lic.sigdata.82a19386b4380a0077d2b55f8934851a
> > +libtool-cross-2.4.2-r3.1.do_populate_sysroot.am335x-evm
> > +libtool-cross-2.4.2-
> r3.1.do_populate_sysroot.sigdata.8c61b5566945f9a439faa916d70a9fd0
> > +libtool-cross-2.4.2-r3.1.do_unpack
> > +libtool-cross-2.4.2-
> r3.1.do_unpack.sigdata.322a15e21f6df957f5ba116da19d5585
> >  linux-libc-headers-3.2-r1.do_compile
> >  linux-libc-headers-3.2-
> r1.do_compile.sigdata.6047c862356fa8f3a56269daf2cde26b
> >  linux-libc-headers-3.2-r1.do_configure
> >
> > Notice that the only stamps for steps done between a passing
> and failing build are for the libtool-cross, as well as the steps
> after the do_configure step of libtool since it passed this time.
> >
> > The work directory difference was
> > -----------------------------------
> > --- libtool-failed-work	2012-10-04 09:17:50.137609986 -0500
> > +++ libtool-passed-work	2012-10-04 09:17:50.137609986 -0500
> > @@ -39,4 +39,5 @@ unifdef-native-2.6.18+git-r0
> >  zlib-native-1.2.6-r1
> >  external-arago-toolchain-1.0-r2
> >  libtool-2.4.2-r3.0
> > +libtool-cross-2.4.2-r3.1
> >  linux-libc-headers-3.2-r1
> >
> > So the only new package I saw show-up in my work directory was
> libtool-cross.
> >
> > Does anyone have any other suggestions of what to look at since
> my
> > testing is showing that adding libtool-cross into the build
> before
> > libtool allows the build to pass.  I'll try going back to the
> internal
> > toolchain instead of my external toolchain as another test to
> run but
> > any other ideas would be appreciated.  Is my approach above
> even
> > valid?
> 
> A list of file differences in the sysroots directory would help
> here.
> Given the above, this amounts to the contents of the libtool-
> cross
> package. Are you able to reproduce this with master or is this
> denzil
> based?

It was denzil based, but once I switched to the internal toolchain instead of using the external toolchain the issue doesn't occur.  So it seems to be rooted in the external toolchain recipe we are using.  Sorry for the confusion and please ignore this patch.

> 
> Cheers,
> 
> Richard

Re: [PATCH] libtool: Add missing DEPENDS on libtool-cross

[Scott Garman]

On 10/04/2012 08:50 AM, Maupin, Chase wrote:
>> -----Original Message----- From: Richard Purdie
>> [mailto:richard.purdie@linuxfoundation.org] Sent: Thursday, October
>> 04, 2012 9:30 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 14:06 +0000, Maupin, Chase wrote:
>>> I tried the following to help narrow this down.  Please let me
>> know if there is something else I could try to help narrow the
>> issue.  I ran:
>>>
>>> bitbake -c cleanall libtool bitbake libtool
>>>
>>> Each time it failed I would get a list of the contents of the
>> work directory and the stamps directory.  My goal here was to be
>> able to find what changed between a pass and a fail.  I kept
>> running the test above until I had a consistent failure, and there
>> were no new packages being added into my work directory and no new
>> stamps being created.  Basically this told me that all the packages
>> that were going to be built from doing "bitbake libtool" were built
>> and that the only package being built was libtool itself.
>>>
>>> I then changed my build steps to do:
>>>
>>> bitbake -c cleanall libtool bitbake libtool-cross bitbake
>>> libtool
>>>
>>> This passed on the first run.  I captured the same work
>> directory contents and stamps contents and then did a diff to see
>> what had changed between these builds.  The diffs were:
>>>
>>> For Stamps diff libtool-failed-stamps libtool-passed-stamps
>>> -----------------------------------------------------------
>>> /arago-tmp-eglibc/stamps$ diff -burpN libtool-failed-stamps
>> libtool-passed-stamps
>>> --- libtool-failed-stamps	2012-10-04 09:11:27.909881710 -0500 +++
>>> libtool-passed-stamps	2012-10-04 09:14:33.997328844 -0500 @@
>>> -23,18 +23,56 @@ external-arago-toolchain-1.0-r2.do_popul
>>> external-arago-toolchain-1.0-
>> r2.do_populate_sysroot.sigdata.bccac35b2b6fecd3cbec49ccc208c6a9
>>> external-arago-toolchain-1.0-r2.do_unpack
>>> external-arago-toolchain-1.0-
>> r2.do_unpack.sigdata.14d8090b51a447ceb4ccf44941781e47
>>> +libtool-2.4.2-r3.0.do_build libtool-2.4.2-r3.0.do_cleansstate
>>> libtool-2.4.2-
>> r3.0.do_cleansstate.sigdata.e2a5d5c89e3be41823e835c18b50dfa3
>>> +libtool-2.4.2-r3.0.do_compile +libtool-2.4.2-
>> r3.0.do_compile.sigdata.ea5125c6ecc524aed598dba3b731d92d
>>> +libtool-2.4.2-r3.0.do_configure +libtool-2.4.2-
>> r3.0.do_configure.sigdata.2e462cacc7c699c75bce74bb7dcf55f4
>>> libtool-2.4.2-r3.0.do_create_srcipk libtool-2.4.2-
>> r3.0.do_create_srcipk.sigdata.caa56f6b8b195ff4e6a063f1288c5f86
>>> libtool-2.4.2-r3.0.do_fetch libtool-2.4.2-
>> r3.0.do_fetch.sigdata.0ccdbfe0aace02237038ae0203de9060
>>> +libtool-2.4.2-r3.0.do_install +libtool-2.4.2-
>> r3.0.do_install.sigdata.9ad203ae762fe0556e7a991ab8a7707c
>>> +libtool-2.4.2-r3.0.do_package.am335x-evm +libtool-2.4.2-
>> r3.0.do_package.sigdata.ffb4b811e7643d5f37afbcffef84f5e8
>>> +libtool-2.4.2-r3.0.do_package_write
>>> +libtool-2.4.2-r3.0.do_package_write_ipk +libtool-2.4.2-
>> r3.0.do_package_write_ipk.sigdata.eb16601f7f4f1afbfabc8542fea3af3
>> 0
>>> libtool-2.4.2-r3.0.do_patch libtool-2.4.2-
>> r3.0.do_patch.sigdata.7d028f6dc6a1bdf32aadc29a6444bebc
>>> libtool-2.4.2-r3.0.do_populate_lic libtool-2.4.2-
>> r3.0.do_populate_lic.sigdata.ebd50cceb0903e1b277ad6f533055373
>>> +libtool-2.4.2-r3.0.do_populate_sysroot.am335x-evm
>>> +libtool-2.4.2-
>> r3.0.do_populate_sysroot.sigdata.43f8d1df81e38dacd301eed5599094f1
>>> libtool-2.4.2-r3.0.do_unpack libtool-2.4.2-
>> r3.0.do_unpack.sigdata.f97c2643ec8f5752b2537f305a45ca7e
>>> +libtool-cross-2.4.2-r3.1.do_build
>>> +libtool-cross-2.4.2-r3.1.do_compile +libtool-cross-2.4.2-
>> r3.1.do_compile.sigdata.c04f058e41aabe9001f0b82764d51d24
>>> +libtool-cross-2.4.2-r3.1.do_configure +libtool-cross-2.4.2-
>> r3.1.do_configure.sigdata.b37940faf1adfcc783e7a66eff351d4b
>>> +libtool-cross-2.4.2-r3.1.do_create_srcipk +libtool-cross-2.4.2-
>> r3.1.do_create_srcipk.sigdata.37082cdfd6eb100923aab805101fe221
>>> +libtool-cross-2.4.2-r3.1.do_fetch +libtool-cross-2.4.2-
>> r3.1.do_fetch.sigdata.79da02e9de369c7964c9b54e291088d5
>>> +libtool-cross-2.4.2-r3.1.do_install +libtool-cross-2.4.2-
>> r3.1.do_install.sigdata.607177b917d48c411c6c2fbaf475867b
>>> +libtool-cross-2.4.2-r3.1.do_package.am335x-evm
>>> +libtool-cross-2.4.2-
>> r3.1.do_package.sigdata.4f0eb910d74ff36b564968e09a8e15f2
>>> +libtool-cross-2.4.2-r3.1.do_package_write
>>> +libtool-cross-2.4.2-r3.1.do_package_write_ipk
>>> +libtool-cross-2.4.2-
>> r3.1.do_package_write_ipk.sigdata.0cc36358a4c5dee1f612fe3a90c60b1
>> a
>>> +libtool-cross-2.4.2-r3.1.do_patch +libtool-cross-2.4.2-
>> r3.1.do_patch.sigdata.a319c3ae77229a7558409abc179ea99d
>>> +libtool-cross-2.4.2-r3.1.do_populate_lic +libtool-cross-2.4.2-
>> r3.1.do_populate_lic.sigdata.82a19386b4380a0077d2b55f8934851a
>>> +libtool-cross-2.4.2-r3.1.do_populate_sysroot.am335x-evm
>>> +libtool-cross-2.4.2-
>> r3.1.do_populate_sysroot.sigdata.8c61b5566945f9a439faa916d70a9fd0
>>> +libtool-cross-2.4.2-r3.1.do_unpack +libtool-cross-2.4.2-
>> r3.1.do_unpack.sigdata.322a15e21f6df957f5ba116da19d5585
>>> linux-libc-headers-3.2-r1.do_compile linux-libc-headers-3.2-
>> r1.do_compile.sigdata.6047c862356fa8f3a56269daf2cde26b
>>> linux-libc-headers-3.2-r1.do_configure
>>>
>>> Notice that the only stamps for steps done between a passing
>> and failing build are for the libtool-cross, as well as the steps
>> after the do_configure step of libtool since it passed this time.
>>>
>>> The work directory difference was
>>> ----------------------------------- --- libtool-failed-work
>>> 2012-10-04 09:17:50.137609986 -0500 +++ libtool-passed-work
>>> 2012-10-04 09:17:50.137609986 -0500 @@ -39,4 +39,5 @@
>>> unifdef-native-2.6.18+git-r0 zlib-native-1.2.6-r1
>>> external-arago-toolchain-1.0-r2 libtool-2.4.2-r3.0
>>> +libtool-cross-2.4.2-r3.1 linux-libc-headers-3.2-r1
>>>
>>> So the only new package I saw show-up in my work directory was
>> libtool-cross.
>>>
>>> Does anyone have any other suggestions of what to look at since
>> my
>>> testing is showing that adding libtool-cross into the build
>> before
>>> libtool allows the build to pass.  I'll try going back to the
>> internal
>>> toolchain instead of my external toolchain as another test to
>> run but
>>> any other ideas would be appreciated.  Is my approach above
>> even
>>> valid?
>>
>> A list of file differences in the sysroots directory would help
>> here. Given the above, this amounts to the contents of the
>> libtool- cross package. Are you able to reproduce this with master
>> or is this denzil based?
>
> It was denzil based, but once I switched to the internal toolchain
> instead of using the external toolchain the issue doesn't occur.  So
> it seems to be rooted in the external toolchain recipe we are using.
> Sorry for the confusion and please ignore this patch.

I have now removed this from my sgarman/deznil-next branches, and this 
happened just in time, as I'm about to start an autobuilder run.

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center