Patchwork [2/5] gcc-4.7: Update to tip of gcc-4_7-branch since 4.7.1 has been out

login
register
mail settings
Submitter Khem Raj
Date June 20, 2012, 3:18 p.m.
Message ID <a1ca534609d8ae49a16b9d28cc9e92db0894c4e4.1340205163.git.raj.khem@gmail.com>
Download mbox | patch
Permalink /patch/30329/
State New
Headers show

Comments

Khem Raj - June 20, 2012, 3:18 p.m.
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(-)
Martin Jansa - June 22, 2012, 6:37 a.m.
On Wed, Jun 20, 2012 at 08:18:37AM -0700, 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"
>  
> -SRCREV = "186651"
> +SRCREV = "188658"
>  BRANCH = "gcc-4_7-branch"
>  FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"

I'm not sure if this one is new, but libgcc now reports unpackaged
file:

NOTE: package libgcc-4.7.1+svnr188658-r2: task do_package: Started
WARNING: For recipe libgcc, the following files/directories were
installed but not shipped in any package:
WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include
WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include/unwind.h

And the problem with (sometimes) missing or corrupt header file is still there:
| /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/dwarf2out.c:8383:6: warning: format not a string literal and no format arguments [-Wformat-security]
| gcc -c   -isystem/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include -O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../include -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libcpp/include  -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber/dpd -I../libdecnumber    /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c -o emit-rtl.o
| /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c:42:17: fatal error: rtl.h: No such file or directory
| compilation terminated.
Restarting build helps again..

Cheers,
Khem Raj - June 22, 2012, 7:20 a.m.
On Thu, Jun 21, 2012 at 11:37 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Wed, Jun 20, 2012 at 08:18:37AM -0700, 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"
>>
>> -SRCREV = "186651"
>> +SRCREV = "188658"
>>  BRANCH = "gcc-4_7-branch"
>>  FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"
>
> I'm not sure if this one is new, but libgcc now reports unpackaged
> file:
>
> NOTE: package libgcc-4.7.1+svnr188658-r2: task do_package: Started
> WARNING: For recipe libgcc, the following files/directories were
> installed but not shipped in any package:
> WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include
> WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include/unwind.h

can you see couple of things 1. if this file is being generated and
installed during libgcc build or if its coming from the bits that are
stashed away from gcc-cross build

this file should not be packaged with libgcc so right solution will be
to delete this file
>
> And the problem with (sometimes) missing or corrupt header file is still there:
> | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/dwarf2out.c:8383:6: warning: format not a string literal and no format arguments [-Wformat-security]
> | gcc -c   -isystem/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include -O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../include -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libcpp/include  -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber/dpd -I../libdecnumber    /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c -o emit-rtl.o
> | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c:42:17: fatal error: rtl.h: No such file or directory
> | compilation terminated.
> Restarting build helps again..
>

this is intriguing we should look into it can you explain (once again
how can I reproduce it)

> Cheers,
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Martin Jansa - June 22, 2012, 7:38 a.m.
On Fri, Jun 22, 2012 at 12:20:31AM -0700, Khem Raj wrote:
> On Thu, Jun 21, 2012 at 11:37 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Wed, Jun 20, 2012 at 08:18:37AM -0700, 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"
> >>
> >> -SRCREV = "186651"
> >> +SRCREV = "188658"
> >>  BRANCH = "gcc-4_7-branch"
> >>  FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"
> >
> > I'm not sure if this one is new, but libgcc now reports unpackaged
> > file:
> >
> > NOTE: package libgcc-4.7.1+svnr188658-r2: task do_package: Started
> > WARNING: For recipe libgcc, the following files/directories were
> > installed but not shipped in any package:
> > WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include
> > WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include/unwind.h
> 
> can you see couple of things 1. if this file is being generated and
> installed during libgcc build or if its coming from the bits that are
> stashed away from gcc-cross build
> 
> this file should not be packaged with libgcc so right solution will be
> to delete this file
> >
> > And the problem with (sometimes) missing or corrupt header file is still there:
> > | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/dwarf2out.c:8383:6: warning: format not a string literal and no format arguments [-Wformat-security]
> > | gcc -c   -isystem/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include -O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../include -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libcpp/include  -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber/dpd -I../libdecnumber    /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c -o emit-rtl.o
> > | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c:42:17: fatal error: rtl.h: No such file or directory
> > | compilation terminated.
> > Restarting build helps again..
> >
> 
> this is intriguing we should look into it can you explain (once again
> how can I reproduce it)

I still don't have any steps how to reproduce it reliably, just doing a
lot of gcc builds and I see about once from 5 builds.. So with every gcc
upgrade (even with just PR bump) I get usually at least 1 build failure
for 1 architecture/machine on one buildhost (sometimes it's on fast one,
sometimes on slow one with just 2 threads - so speed is not so important
to reproduce it).

Usually it's from gcc-cross-initial, but sometimes from intermediate or
gcc-cross itself too.

The error is different from time to time, but always some constant
missing or whole header file like in today's error. Probably most
popular one is
/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.0+svnr186651-r1/gcc-4_7-branch/gcc/calls.c:1204:9:
error: 'STACK_CHECK_MAX_VAR_SIZE' undeclared (first use in this
function)

whole log in 
http://build.shr-project.org/tests/jama/gcc-issue/gcc-race-new/

even more samples:
http://build.shr-project.org/tests/jama/gcc-upgrade-issue/

I'm sorry I cannot provide better info.

Cheers,
Saul Wold - June 22, 2012, 10:21 p.m.
On 06/22/2012 12:20 AM, Khem Raj wrote:
> On Thu, Jun 21, 2012 at 11:37 PM, Martin Jansa<martin.jansa@gmail.com>  wrote:
>> On Wed, Jun 20, 2012 at 08:18:37AM -0700, 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"
>>>
>>> -SRCREV = "186651"
>>> +SRCREV = "188658"
>>>   BRANCH = "gcc-4_7-branch"
>>>   FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"
>>
>> I'm not sure if this one is new, but libgcc now reports unpackaged
>> file:
>>
>> NOTE: package libgcc-4.7.1+svnr188658-r2: task do_package: Started
>> WARNING: For recipe libgcc, the following files/directories were
>> installed but not shipped in any package:
>> WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include
>> WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include/unwind.h
>
> can you see couple of things 1. if this file is being generated and
> installed during libgcc build or if its coming from the bits that are
> stashed away from gcc-cross build
>
Khem, this file seems to be set up during do_configure time

config.status: linking 
/srv/ssd/sgw_ab/builds/repack/tmp/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/libgcc/unwind-generic.h 
to unwind.h

> this file should not be packaged with libgcc so right solution will be
> to delete this file

Will you provide the patch please.

Thanks
	Sau!

>>
>> And the problem with (sometimes) missing or corrupt header file is still there:
>> | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/dwarf2out.c:8383:6: warning: format not a string literal and no format arguments [-Wformat-security]
>> | gcc -c   -isystem/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include -O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../include -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libcpp/include  -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber/dpd -I../libdecnumber    /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2
/gcc-4_7-branch/gcc/emit-rtl.c -o emit-rtl.o
>> | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c:42:17: fatal error: rtl.h: No such file or directory
>> | compilation terminated.
>> Restarting build helps again..
>>
>
> this is intriguing we should look into it can you explain (once again
> how can I reproduce it)
>
>> Cheers,
>>
>> --
>> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - June 22, 2012, 11:50 p.m.
On Fri, Jun 22, 2012 at 3:21 PM, Saul Wold <sgw@linux.intel.com> wrote:
> On 06/22/2012 12:20 AM, Khem Raj wrote:
>>
>> On Thu, Jun 21, 2012 at 11:37 PM, Martin Jansa<martin.jansa@gmail.com>
>>  wrote:
>>>
>>> On Wed, Jun 20, 2012 at 08:18:37AM -0700, 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"
>>>>
>>>> -SRCREV = "186651"
>>>> +SRCREV = "188658"
>>>>  BRANCH = "gcc-4_7-branch"
>>>>  FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"
>>>
>>>
>>> I'm not sure if this one is new, but libgcc now reports unpackaged
>>> file:
>>>
>>> NOTE: package libgcc-4.7.1+svnr188658-r2: task do_package: Started
>>> WARNING: For recipe libgcc, the following files/directories were
>>> installed but not shipped in any package:
>>> WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include
>>> WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include/unwind.h
>>
>>
>> can you see couple of things 1. if this file is being generated and
>> installed during libgcc build or if its coming from the bits that are
>> stashed away from gcc-cross build
>>
> Khem, this file seems to be set up during do_configure time
>
> config.status: linking
> /srv/ssd/sgw_ab/builds/repack/tmp/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/libgcc/unwind-generic.h
> to unwind.h
>
>
>> this file should not be packaged with libgcc so right solution will be
>> to delete this file
>
>
> Will you provide the patch please.
>

eventually yes if no one beats me to it.
Martin Jansa - July 10, 2012, 7:52 a.m.
On Fri, Jun 22, 2012 at 09:38:38AM +0200, Martin Jansa wrote:
> On Fri, Jun 22, 2012 at 12:20:31AM -0700, Khem Raj wrote:
> > On Thu, Jun 21, 2012 at 11:37 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > On Wed, Jun 20, 2012 at 08:18:37AM -0700, 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"
> > >>
> > >> -SRCREV = "186651"
> > >> +SRCREV = "188658"
> > >>  BRANCH = "gcc-4_7-branch"
> > >>  FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"
> > >
> > > I'm not sure if this one is new, but libgcc now reports unpackaged
> > > file:
> > >
> > > NOTE: package libgcc-4.7.1+svnr188658-r2: task do_package: Started
> > > WARNING: For recipe libgcc, the following files/directories were
> > > installed but not shipped in any package:
> > > WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include
> > > WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include/unwind.h
> > 
> > can you see couple of things 1. if this file is being generated and
> > installed during libgcc build or if its coming from the bits that are
> > stashed away from gcc-cross build
> > 
> > this file should not be packaged with libgcc so right solution will be
> > to delete this file
> > >
> > > And the problem with (sometimes) missing or corrupt header file is still there:
> > > | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/dwarf2out.c:8383:6: warning: format not a string literal and no format arguments [-Wformat-security]
> > > | gcc -c   -isystem/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include -O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../include -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libcpp/include  -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber/dpd -I../libdecnumber    /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c -o emit-rtl.o
> > > | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c:42:17: fatal error: rtl.h: No such file or directory
> > > | compilation terminated.
> > > Restarting build helps again..
> > >
> > 
> > this is intriguing we should look into it can you explain (once again
> > how can I reproduce it)
> 
> I still don't have any steps how to reproduce it reliably, just doing a
> lot of gcc builds and I see about once from 5 builds.. So with every gcc
> upgrade (even with just PR bump) I get usually at least 1 build failure
> for 1 architecture/machine on one buildhost (sometimes it's on fast one,
> sometimes on slow one with just 2 threads - so speed is not so important
> to reproduce it).
> 
> Usually it's from gcc-cross-initial, but sometimes from intermediate or
> gcc-cross itself too.
> 
> The error is different from time to time, but always some constant
> missing or whole header file like in today's error. Probably most
> popular one is
> /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.0+svnr186651-r1/gcc-4_7-branch/gcc/calls.c:1204:9:
> error: 'STACK_CHECK_MAX_VAR_SIZE' undeclared (first use in this
> function)
> 
> whole log in 
> http://build.shr-project.org/tests/jama/gcc-issue/gcc-race-new/
> 
> even more samples:
> http://build.shr-project.org/tests/jama/gcc-upgrade-issue/
> 
> I'm sorry I cannot provide better info.

I guess this was caused by subversion-native in sstate checksums
which was fixed in:
http://git.openembedded.org/openembedded-core/commit/?id=793ce6cd9aa632e0f13789c8293770a86085d28d

because I was using subversion-native for long, so that can explain why
I was only one seeing those gcc issues

Cheers,
Khem Raj - July 10, 2012, 1:38 p.m.
-Khem

On Jul 10, 2012, at 12:52 AM, Martin Jansa <martin.jansa@gmail.com> wrote:

> On Fri, Jun 22, 2012 at 09:38:38AM +0200, Martin Jansa wrote:
>> On Fri, Jun 22, 2012 at 12:20:31AM -0700, Khem Raj wrote:
>>> On Thu, Jun 21, 2012 at 11:37 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>> On Wed, Jun 20, 2012 at 08:18:37AM -0700, 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"
>>>>> 
>>>>> -SRCREV = "186651"
>>>>> +SRCREV = "188658"
>>>>>  BRANCH = "gcc-4_7-branch"
>>>>>  FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"
>>>> 
>>>> I'm not sure if this one is new, but libgcc now reports unpackaged
>>>> file:
>>>> 
>>>> NOTE: package libgcc-4.7.1+svnr188658-r2: task do_package: Started
>>>> WARNING: For recipe libgcc, the following files/directories were
>>>> installed but not shipped in any package:
>>>> WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include
>>>> WARNING:   /usr/lib/arm-oe-linux-gnueabi/4.7.2/include/unwind.h
>>> 
>>> can you see couple of things 1. if this file is being generated and
>>> installed during libgcc build or if its coming from the bits that are
>>> stashed away from gcc-cross build
>>> 
>>> this file should not be packaged with libgcc so right solution will be
>>> to delete this file
>>>> 
>>>> And the problem with (sometimes) missing or corrupt header file is still there:
>>>> | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/dwarf2out.c:8383:6: warning: format not a string literal and no format arguments [-Wformat-security]
>>>> | gcc -c   -isystem/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include -O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/. -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../include -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libcpp/include  -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber -I/OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/../libdecnumber/dpd -I../libdecnumber    /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c -o emit-rtl.o
>>>> | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.1+svnr188658-r2/gcc-4_7-branch/gcc/emit-rtl.c:42:17: fatal error: rtl.h: No such file or directory
>>>> | compilation terminated.
>>>> Restarting build helps again..
>>>> 
>>> 
>>> this is intriguing we should look into it can you explain (once again
>>> how can I reproduce it)
>> 
>> I still don't have any steps how to reproduce it reliably, just doing a
>> lot of gcc builds and I see about once from 5 builds.. So with every gcc
>> upgrade (even with just PR bump) I get usually at least 1 build failure
>> for 1 architecture/machine on one buildhost (sometimes it's on fast one,
>> sometimes on slow one with just 2 threads - so speed is not so important
>> to reproduce it).
>> 
>> Usually it's from gcc-cross-initial, but sometimes from intermediate or
>> gcc-cross itself too.
>> 
>> The error is different from time to time, but always some constant
>> missing or whole header file like in today's error. Probably most
>> popular one is
>> /OE/shr-core/tmp-eglibc/work-shared/gcc-4.7.0+svnr186651-r1/gcc-4_7-branch/gcc/calls.c:1204:9:
>> error: 'STACK_CHECK_MAX_VAR_SIZE' undeclared (first use in this
>> function)
>> 
>> whole log in 
>> http://build.shr-project.org/tests/jama/gcc-issue/gcc-race-new/
>> 
>> even more samples:
>> http://build.shr-project.org/tests/jama/gcc-upgrade-issue/
>> 
>> I'm sorry I cannot provide better info.
> 
> I guess this was caused by subversion-native in sstate checksums
> which was fixed in:
> http://git.openembedded.org/openembedded-core/commit/?id=793ce6cd9aa632e0f13789c8293770a86085d28d
> 
> because I was using subversion-native for long, so that can explain why
> I was only one seeing those gcc issues

Interesting , do you think it was sort of a race

> 
> Cheers,
> 
> -- 
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Patch

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"
 
-SRCREV = "186651"
+SRCREV = "188658"
 BRANCH = "gcc-4_7-branch"
 FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}"