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.ja...@gmail.com>
> > wrote:
> > > On Wed, Jun 20, 2012 at 08:18:37AM -0700, Khem Raj wrote:
> > >> Signed-off-by: Khem Raj <raj.k...@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, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
