From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] gcc: Ensure that the shared source directory shared the same sstate hashes
Date: Fri, 20 Jan 2012 13:38:53 +0000 [thread overview]
Message-ID: <1327066733.4268.1.camel@ted> (raw)
In-Reply-To: <857BE142E5399E46B20FD45B9DB8A7BC0FCC088E@SHSMSX102.ccr.corp.intel.com>
On Fri, 2012-01-20 at 08:49 +0000, Lu, Lianhao wrote:
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> > Of Saul Wold
> > Sent: Friday, January 20, 2012 4:19 PM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [PATCH] gcc: Ensure that the shared source directory shared the same sstate hashes
> >
> > On 01/19/2012 11:38 AM, Richard Purdie wrote:
> > > The fetch/unpack/patch/headerfix tasks are shared and hence their sstate hashes
> > > should also match. Sadly this is not the case since:
> > >
> > > a) gcc-runtime applies an additional patch
> > > b) The do_headerfix task was missing from libgcc
> > > c) The do_headerfix task is a shell task and hence depends
> > > on all exported variables which can vary between cross and target
> > > recipes.
> > >
> > > To fix this, the patch moves the patch to the common code, adds
> > > the headerfix task to a common include file and disabled shell
> > > dependencies on the do_headerfix task since its clear in this case
> > > we don't need thsoe dependencies since we just call sed.
> > >
> > > With this patch applied, all these recipes now share common sstate checksums.
> > >
> > Richard,
> >
> > I tried both a sstate build with and existing tmp and a clean tmp, the
> > existing tmp seemed to work ok, but with a clean tmp (and sstate), I got
> > the following patch issue still.
> >
> > This was with BB_SIGNATURE_HANDLER ?= 'basichash' set.
> >
> > ERROR: Command Error: exit status: 1 Output:
> > Could not link file
> > `.pc/gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch/configure' to `configure': No
> > such file or directory
> > Applying patch gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch
> > patching file configure.ac
> > Hunk #1 FAILED at 3073.
> > 1 out of 1 hunk FAILED -- rejects in file configure.ac
> > patching file configure
> > Hunk #1 FAILED at 7594.
> > 1 out of 1 hunk FAILED -- rejects in file configure
> > Patch gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch does not apply (enforce with -f)
> > ERROR: Function failed: patch_do_patch
> > ERROR: Logfile of failure stored in:
> > /intel/poky2/builds/binutils/tmp/work-shared/gcc-4.6.2+svnr181430-r20/temp/log.do_patch.15457
> > NOTE: package libgcc-4.6.2+svnr181430-r20: task do_patch: Failed
> > ERROR: Task 882
> > (/intel/poky2/distro/meta/recipes-devtools/gcc/libgcc_4.6.bb, do_patch)
> > failed with exit code '1'
> >
> > I have not tried a clean sstate / clean tmp.
> >
> Well, using the poky-conrib/rpurdie/t1 branch, it seems that the libgcc still has different signature with
> gcc-cross-initial for task patch. But bitbake-diffsigs reports nothing. gcc-runtime seems to be ok now.
I looked into this and the problem is that the quilt-native dependency
is removed in the target cases (libgcc/gcc-runtime) but not in the cross
cases thanks to BB_HASHTASK_WHITELIST. I'm trying to figure out how to
solve that.
Cheers,
Richard
next prev parent reply other threads:[~2012-01-20 13:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-19 19:38 [PATCH] gcc: Ensure that the shared source directory shared the same sstate hashes Richard Purdie
2012-01-20 8:19 ` Saul Wold
2012-01-20 8:49 ` Lu, Lianhao
2012-01-20 13:38 ` Richard Purdie [this message]
2012-01-20 17:04 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1327066733.4268.1.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox