| Message ID | a1ca534609d8ae49a16b9d28cc9e92db0894c4e4.1340205163.git.raj.khem@gmail.com |
|---|---|
| State | New |
| Headers | show |
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)}"
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,
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 >
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,
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
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.
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 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
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(-)