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