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

Tue Jul 10 13:38:47 UTC 2012

-Khem

On Jul 10, 2012, at 12:52 AM, Martin Jansa <martin.jansa at 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 at gmail.com> wrote:
>>>> On Wed, Jun 20, 2012 at 08:18:37AM -0700, Khem Raj wrote:
>>>>> Signed-off-by: Khem Raj <raj.khem at 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 at gmail.com
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core