All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: Saul Wold <sgw@linux.intel.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] gcc-4.7: Update to tip of gcc-4_7-branch since 4.7.1 has been out
Date: Fri, 22 Jun 2012 21:22:49 -0700	[thread overview]
Message-ID: <4FE54499.8040304@gmail.com> (raw)
In-Reply-To: <4FE54346.5080401@linux.intel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/22/2012 9:17 PM, Saul Wold wrote:
> On 06/19/2012 08:43 AM, Khem Raj wrote:
>> Signed-off-by: Khem Raj<raj.khem@gmail.com> --- 
>> meta/recipes-devtools/gcc/gcc-4.7.inc |   12 ++++++------ 1 files
>> changed, 6 insertions(+), 6 deletions(-)
>> 
>> diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc 
>> b/meta/recipes-devtools/gcc/gcc-4.7.inc index 34a73b1..25a1088
>> 100644 --- a/meta/recipes-devtools/gcc/gcc-4.7.inc +++
>> b/meta/recipes-devtools/gcc/gcc-4.7.inc @@ -3,12 +3,12 @@ require
>> gcc-common.inc PR = "r2"
>> 
>> # Third digit in PV should be incremented after a minor release 
>> -# happens from this branch on gcc e.g. currently its 4.7.0 -#
>> when 4.7.1 is releases and we bump SRCREV beyond the release -#
>> on branch then PV should be incremented to 4.7.1+svnr${SRCPV} +#
>> happens from this branch on gcc e.g. currently its 4.7.1 +# when
>> 4.7.2 is releases and we bump SRCREV beyond the release +# on
>> branch then PV should be incremented to 4.7.2+svnr${SRCPV} # to
>> reflect that change
>> 
>> -PV = "4.7.0+svnr${SRCPV}" +PV = "4.7.1+svnr${SRCPV}"
>> 
>> # BINV should be incremented after updating to a revision # after
>> a minor gcc release (e.g. 4.7.1 or 4.7.2) has been made @@ -16,9
>> +16,9 @@ PV = "4.7.0+svnr${SRCPV}" # 4.7.1 then the value below
>> will have 2 which will mean 4.7.2 # which will be next minor
>> release and so on.
>> 
>> -BINV = "4.7.1" +BINV = "4.7.2"
>> 
> I merged this and had tested it on the Autobuilder, but I just
> tried another build locally and got a grouping of failures that may
> have used sstate because they failed do_compile: 
> /srv/ssd/sgw_ab/poky/meta/recipes-extended/newt/libnewt_0.52.14.bb,
>
> 
do_compile
> /srv/ssd/sgw_ab/poky/meta/recipes-graphics/mesa/mesa-dri_7.11.bb, 
> do_compile 
> /srv/ssd/sgw_ab/poky/meta/recipes-kernel/trace-cmd/trace-cmd_1.2.bb,
>
> 
do_compile
> 
> /srv/ssd/sgw_ab/poky/meta/recipes-extended/logrotate/logrotate_3.8.1.bb,
>
> 
do_compile
> /srv/ssd/sgw_ab/poky/meta/recipes-kernel/kexec/kexec-tools_2.0.3.bb,
>
> 
do_compile
> 
> /srv/ssd/sgw_ab/poky/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb,
>
> 
do_compile
> 
> /srv/ssd/sgw_ab/poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb,
>
> 
do_compile
> /srv/ssd/sgw_ab/poky/meta/recipes-devtools/apt/apt_0.7.14.bb,
> do_compile
> 
> 
> The failure was: | make: *** No rule to make target 
> `/srv/ssd/sgw_ab/builds/repack/tmp/sysroots/x86_64-linux/usr/lib/i586-poky-linux/gcc/i586-poky-linux/4.7.1/include/stddef.h',
>
> 
needed by `logrotate.o'.  Stop.
> 
> Note the 4.7.1!
> 
> A clean solved the issue, so I am not sure where it's picking up
> the 4.7.1 from during the do_configure.
> 
> More investigation is required!
> 

sstate for these packages should have been invalidated. I wonder if
this header path is being added to makefile rules when they are
generated first time but then it escapes the hash calculations when
doing sstate checksumming

> Sau!
> 
> 
> 
> 
>> -SRCREV = "186651" +SRCREV = "188658" BRANCH = "gcc-4_7-branch" 
>> FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ],
>> d)}"
>> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/lRJkACgkQuwUzVZGdMxTVpwCfRP+X+vR3KDpLA6LKra/70dhy
ad8AoImd9xian0gRV74yPx17jlt8TiWF
=E/5h
-----END PGP SIGNATURE-----



      reply	other threads:[~2012-06-23  4:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-19 15:43 [PATCH] gcc-4.7: Update to tip of gcc-4_7-branch since 4.7.1 has been out Khem Raj
2012-06-22 17:50 ` Saul Wold
2012-06-23  4:17 ` Saul Wold
2012-06-23  4:22   ` Khem Raj [this message]

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=4FE54499.8040304@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=sgw@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.