On 10/04/2012 08:50 AM, Maupin, Chase wrote:
-----Original Message----- From: Richard Purdie
[mailto:[email protected]] Sent: Thursday, October
04, 2012 9:30 AM To: Maupin, Chase Cc:
[email protected] 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

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to