* [PATCH 0/4] GCC fixes and updates
@ 2012-09-06 4:35 Khem Raj
2012-09-06 4:35 ` [PATCH 1/4] gcc: Switch SRC_URI to use svn Khem Raj
` (5 more replies)
0 siblings, 6 replies; 29+ messages in thread
From: Khem Raj @ 2012-09-06 4:35 UTC (permalink / raw)
To: openembedded-core
This patchset switches us back to using svn for SRC_URI
and fixes building for armv4 and ppc soft float targets
Finally fixes for libgcc to build with new build sequence
such that its same with gcc-cross and gcc-cross-initial
The following changes since commit 610f8c0c0cab8e258919689fd641faec28b58caf:
adt-installer: Allow changing YOCTOADT_REPO (2012-09-05 23:27:31 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib kraj/gcc-updates
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/gcc-updates
Khem Raj (4):
gcc: Switch SRC_URI to use svn
gcc-4.7: Fix build for armv4/EABI and ppc/Os
arch-armv4.inc: On armv4 add --fix-v4bx to linker flags for kernel
gcc-4.7: Backport libgcc fixes to appease the new build sequence
meta/conf/machine/include/arm/arch-armv4.inc | 1 +
meta/recipes-devtools/gcc/gcc-4.7.inc | 14 +--
...-vis_hide-gen-hide-list-Do-not-make-defin.patch | 93 ++++++++++++++++++++
...USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch | 49 +++++++++++
.../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch | 29 ++++++
.../gcc/gcc-4.7/ppc_no_crtsavres.patch | 21 +++++
6 files changed, 202 insertions(+), 5 deletions(-)
create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch
create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch
create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch
create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch
--
1.7.9.5
^ permalink raw reply [flat|nested] 29+ messages in thread* [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-06 4:35 [PATCH 0/4] GCC fixes and updates Khem Raj @ 2012-09-06 4:35 ` Khem Raj 2012-09-06 7:05 ` Koen Kooi 2012-09-12 2:44 ` Gary Thomas 2012-09-06 4:35 ` [PATCH 2/4] gcc-4.7: Fix build for armv4/EABI and ppc/Os Khem Raj ` (4 subsequent siblings) 5 siblings, 2 replies; 29+ messages in thread From: Khem Raj @ 2012-09-06 4:35 UTC (permalink / raw) To: openembedded-core svn tar balls are 96M as compared to 1.3G git tars its unnessary to suck in that much of data. Fixes [YOCTO #2908] Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-devtools/gcc/gcc-4.7.inc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc index 84c230c..affbd54 100644 --- a/meta/recipes-devtools/gcc/gcc-4.7.inc +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc @@ -11,7 +11,7 @@ PR = "r11" # using 4.7.1.0 for upgrade path when we move past 4.7.2 release # then we should drop the last 0 as well. -PV = "4.7.1.0+git${SRCPV}" +PV = "4.7.1.0+svn${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 @@ -21,7 +21,7 @@ PV = "4.7.1.0+git${SRCPV}" BINV = "4.7.2" -SRCREV = "d07e24f4ab59f264d68d21838795349faab5dede" +SRCREV = "190218" BRANCH = "gcc-4_7-branch" FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}" @@ -36,7 +36,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \ file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \ file://COPYING.RUNTIME;md5=fe60d87048567d4fe8c8a0ed2448bcc8" -SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \ +SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};protocol=http \ file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch \ file://100-uclibc-conf.patch \ file://gcc-uclibc-locale-ctype_touplow_t.patch \ @@ -77,7 +77,7 @@ SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \ file://libtool.patch \ " -S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git" +S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${BRANCH}" B = "${WORKDIR}/${BRANCH}/build.${HOST_SYS}.${TARGET_SYS}" # Language Overrides -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-06 4:35 ` [PATCH 1/4] gcc: Switch SRC_URI to use svn Khem Raj @ 2012-09-06 7:05 ` Koen Kooi 2012-09-12 2:44 ` Gary Thomas 1 sibling, 0 replies; 29+ messages in thread From: Koen Kooi @ 2012-09-06 7:05 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core Op 6 sep. 2012, om 06:35 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven: > svn tar balls are 96M as compared to 1.3G git tars > its unnessary to suck in that much of data. > > Fixes [YOCTO #2908] > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > --- > meta/recipes-devtools/gcc/gcc-4.7.inc | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc > index 84c230c..affbd54 100644 > --- a/meta/recipes-devtools/gcc/gcc-4.7.inc > +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc > @@ -11,7 +11,7 @@ PR = "r11" > # using 4.7.1.0 for upgrade path when we move past 4.7.2 release > # then we should drop the last 0 as well. > > -PV = "4.7.1.0+git${SRCPV}" > +PV = "4.7.1.0+svn${SRCPV}" Note that we can't switch back without either bumping PE or moving to 4.7.x. where x > 1 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-06 4:35 ` [PATCH 1/4] gcc: Switch SRC_URI to use svn Khem Raj 2012-09-06 7:05 ` Koen Kooi @ 2012-09-12 2:44 ` Gary Thomas 2012-09-12 14:08 ` Richard Purdie 1 sibling, 1 reply; 29+ messages in thread From: Gary Thomas @ 2012-09-12 2:44 UTC (permalink / raw) To: openembedded-core On 2012-09-05 22:35, Khem Raj wrote: > svn tar balls are 96M as compared to 1.3G git tars > its unnessary to suck in that much of data. > > Fixes [YOCTO #2908] > > Signed-off-by: Khem Raj <raj.khem@gmail.com> What about this patch? Carrying around a 1.7GB (Sorry, Khem, that's the size of my tar ball!) is a bit much, especially when that's what I send to my customers... > --- > meta/recipes-devtools/gcc/gcc-4.7.inc | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc > index 84c230c..affbd54 100644 > --- a/meta/recipes-devtools/gcc/gcc-4.7.inc > +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc > @@ -11,7 +11,7 @@ PR = "r11" > # using 4.7.1.0 for upgrade path when we move past 4.7.2 release > # then we should drop the last 0 as well. > > -PV = "4.7.1.0+git${SRCPV}" > +PV = "4.7.1.0+svn${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 > @@ -21,7 +21,7 @@ PV = "4.7.1.0+git${SRCPV}" > > BINV = "4.7.2" > > -SRCREV = "d07e24f4ab59f264d68d21838795349faab5dede" > +SRCREV = "190218" > BRANCH = "gcc-4_7-branch" > FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.7' ], d)}" > > @@ -36,7 +36,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \ > file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \ > file://COPYING.RUNTIME;md5=fe60d87048567d4fe8c8a0ed2448bcc8" > > -SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \ > +SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};protocol=http \ > file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch \ > file://100-uclibc-conf.patch \ > file://gcc-uclibc-locale-ctype_touplow_t.patch \ > @@ -77,7 +77,7 @@ SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \ > file://libtool.patch \ > " > > -S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git" > +S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${BRANCH}" > B = "${WORKDIR}/${BRANCH}/build.${HOST_SYS}.${TARGET_SYS}" > > # Language Overrides > -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-12 2:44 ` Gary Thomas @ 2012-09-12 14:08 ` Richard Purdie 2012-09-12 15:34 ` Khem Raj 0 siblings, 1 reply; 29+ messages in thread From: Richard Purdie @ 2012-09-12 14:08 UTC (permalink / raw) To: Gary Thomas; +Cc: openembedded-core On Tue, 2012-09-11 at 20:44 -0600, Gary Thomas wrote: > On 2012-09-05 22:35, Khem Raj wrote: > > svn tar balls are 96M as compared to 1.3G git tars > > its unnessary to suck in that much of data. > > > > Fixes [YOCTO #2908] > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > What about this patch? Carrying around a 1.7GB (Sorry, Khem, that's the size of my tar ball!) > is a bit much, especially when that's what I send to my customers... I've been hoping to find some time to do something with the fetcher to try and fix this corner we've ended up pinned into. Ideally I'd like to see both gcc and eglibc using git, we have git in ASSUME_PROVIDED and everything is optimal. I'm not going to reach the release point without doing something about this but I would like to stick with git if we can possibly help it. Having to build subversion-native for critical path components is a major pain and performance issue. Cheers, Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-12 14:08 ` Richard Purdie @ 2012-09-12 15:34 ` Khem Raj 2012-09-13 12:19 ` Björn Stenberg 0 siblings, 1 reply; 29+ messages in thread From: Khem Raj @ 2012-09-12 15:34 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 1611 bytes --] On Wednesday, September 12, 2012, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Tue, 2012-09-11 at 20:44 -0600, Gary Thomas wrote: >> On 2012-09-05 22:35, Khem Raj wrote: >> > svn tar balls are 96M as compared to 1.3G git tars >> > its unnessary to suck in that much of data. >> > >> > Fixes [YOCTO #2908] >> > >> > Signed-off-by: Khem Raj <raj.khem@gmail.com> >> >> What about this patch? Carrying around a 1.7GB (Sorry, Khem, that's the size of my tar ball!) >> is a bit much, especially when that's what I send to my customers... > > I've been hoping to find some time to do something with the fetcher to > try and fix this corner we've ended up pinned into. > > Ideally I'd like to see both gcc and eglibc using git, we have git in > ASSUME_PROVIDED and everything is optimal. > > I'm not going to reach the release point without doing something about > this but I would like to stick with git if we can possibly help it. > > Having to build subversion-native for critical path components is a > major pain and performance issue. > I agree but then 1.7 GB is noticeably huge too and it will only become larger in future so I don't think fetching from git will be a good solution for gcc ever. I was thinking we could Generate tar ball ourselves and put it on yp mirror. And in future use up stream release tar balls. > Cheers, > > Richard > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > [-- Attachment #2: Type: text/html, Size: 2132 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-12 15:34 ` Khem Raj @ 2012-09-13 12:19 ` Björn Stenberg 2012-09-13 13:06 ` Otavio Salvador 0 siblings, 1 reply; 29+ messages in thread From: Björn Stenberg @ 2012-09-13 12:19 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core Khem Raj wrote: > I agree but then 1.7 GB is noticeably huge too and it will only become > larger in future so I don't think fetching from git will be a good solution > for gcc ever. Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. -- Björn ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-13 12:19 ` Björn Stenberg @ 2012-09-13 13:06 ` Otavio Salvador 2012-09-13 14:22 ` Chris Larson 0 siblings, 1 reply; 29+ messages in thread From: Otavio Salvador @ 2012-09-13 13:06 UTC (permalink / raw) To: Björn Stenberg; +Cc: openembedded-core On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: > Khem Raj wrote: >> I agree but then 1.7 GB is noticeably huge too and it will only become >> larger in future so I don't think fetching from git will be a good solution >> for gcc ever. > > Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. I did not check if the fetcher has this support but it would be a nice solution. -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-13 13:06 ` Otavio Salvador @ 2012-09-13 14:22 ` Chris Larson 2012-09-14 11:58 ` Richard Purdie 0 siblings, 1 reply; 29+ messages in thread From: Chris Larson @ 2012-09-13 14:22 UTC (permalink / raw) To: Otavio Salvador; +Cc: openembedded-core On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador <otavio@ossystems.com.br> wrote: > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: >> Khem Raj wrote: >>> I agree but then 1.7 GB is noticeably huge too and it will only become >>> larger in future so I don't think fetching from git will be a good solution >>> for gcc ever. >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. > > I did not check if the fetcher has this support but it would be a > nice solution. Shallow clones won't be able to support SRCREV properly, as you can only clone shallowly from HEAD, not from an arbitrary point in history, AFAIK. -- Christopher Larson ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-13 14:22 ` Chris Larson @ 2012-09-14 11:58 ` Richard Purdie 0 siblings, 0 replies; 29+ messages in thread From: Richard Purdie @ 2012-09-14 11:58 UTC (permalink / raw) To: Chris Larson; +Cc: bitbake-devel, Otavio Salvador, openembedded-core On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: > On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador > <otavio@ossystems.com.br> wrote: > > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: > >> Khem Raj wrote: > >>> I agree but then 1.7 GB is noticeably huge too and it will only become > >>> larger in future so I don't think fetching from git will be a good solution > >>> for gcc ever. > >> > >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. > > > > I did not check if the fetcher has this support but it would be a > > nice solution. > > Shallow clones won't be able to support SRCREV properly, as you can > only clone shallowly from HEAD, not from an arbitrary point in > history, AFAIK. Right, shallow clones are a can of worms from a variety of angles. My current thinking is a ;allowsinglerev=1 parameter to the git fetcher which: a) Generates tarballs of single git revisions if tarball generation is turned on b) Searches for single revision tarballs before trying the main checkout approach. This would mean that WORKDIR may or may not have a .git directory for any SRC_URI marked with this. I think we should all be able to live with that and it shouldn't break too much? Cheers, Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn @ 2012-09-14 11:58 ` Richard Purdie 0 siblings, 0 replies; 29+ messages in thread From: Richard Purdie @ 2012-09-14 11:58 UTC (permalink / raw) To: Chris Larson; +Cc: bitbake-devel, openembedded-core On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: > On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador > <otavio@ossystems.com.br> wrote: > > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: > >> Khem Raj wrote: > >>> I agree but then 1.7 GB is noticeably huge too and it will only become > >>> larger in future so I don't think fetching from git will be a good solution > >>> for gcc ever. > >> > >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. > > > > I did not check if the fetcher has this support but it would be a > > nice solution. > > Shallow clones won't be able to support SRCREV properly, as you can > only clone shallowly from HEAD, not from an arbitrary point in > history, AFAIK. Right, shallow clones are a can of worms from a variety of angles. My current thinking is a ;allowsinglerev=1 parameter to the git fetcher which: a) Generates tarballs of single git revisions if tarball generation is turned on b) Searches for single revision tarballs before trying the main checkout approach. This would mean that WORKDIR may or may not have a .git directory for any SRC_URI marked with this. I think we should all be able to live with that and it shouldn't break too much? Cheers, Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-14 11:58 ` Richard Purdie @ 2012-09-14 12:31 ` Bruce Ashfield -1 siblings, 0 replies; 29+ messages in thread From: Bruce Ashfield @ 2012-09-14 12:31 UTC (permalink / raw) To: Richard Purdie; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, Sep 14, 2012 at 7:58 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador >> <otavio@ossystems.com.br> wrote: >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: >> >> Khem Raj wrote: >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become >> >>> larger in future so I don't think fetching from git will be a good solution >> >>> for gcc ever. >> >> >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. >> > >> > I did not check if the fetcher has this support but it would be a >> > nice solution. >> >> Shallow clones won't be able to support SRCREV properly, as you can >> only clone shallowly from HEAD, not from an arbitrary point in >> history, AFAIK. > > Right, shallow clones are a can of worms from a variety of angles. > > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher > which: > > a) Generates tarballs of single git revisions if tarball generation is > turned on > b) Searches for single revision tarballs before trying the main checkout > approach. > > This would mean that WORKDIR may or may not have a .git directory for > any SRC_URI marked with this. I think we should all be able to live with > that and it shouldn't break too much? Sounds ok to me, and there are other uses like my nearly completed 'low bandwidth' yocto kernel recipe tweaks that should be able to leverage something like this as well. Cheers, Bruce > > Cheers, > > Richard > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn @ 2012-09-14 12:31 ` Bruce Ashfield 0 siblings, 0 replies; 29+ messages in thread From: Bruce Ashfield @ 2012-09-14 12:31 UTC (permalink / raw) To: Richard Purdie; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, Sep 14, 2012 at 7:58 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador >> <otavio@ossystems.com.br> wrote: >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: >> >> Khem Raj wrote: >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become >> >>> larger in future so I don't think fetching from git will be a good solution >> >>> for gcc ever. >> >> >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. >> > >> > I did not check if the fetcher has this support but it would be a >> > nice solution. >> >> Shallow clones won't be able to support SRCREV properly, as you can >> only clone shallowly from HEAD, not from an arbitrary point in >> history, AFAIK. > > Right, shallow clones are a can of worms from a variety of angles. > > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher > which: > > a) Generates tarballs of single git revisions if tarball generation is > turned on > b) Searches for single revision tarballs before trying the main checkout > approach. > > This would mean that WORKDIR may or may not have a .git directory for > any SRC_URI marked with this. I think we should all be able to live with > that and it shouldn't break too much? Sounds ok to me, and there are other uses like my nearly completed 'low bandwidth' yocto kernel recipe tweaks that should be able to leverage something like this as well. Cheers, Bruce > > Cheers, > > Richard > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-14 11:58 ` Richard Purdie @ 2012-09-14 12:36 ` Otavio Salvador -1 siblings, 0 replies; 29+ messages in thread From: Otavio Salvador @ 2012-09-14 12:36 UTC (permalink / raw) To: Richard Purdie; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador >> <otavio@ossystems.com.br> wrote: >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: >> >> Khem Raj wrote: >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become >> >>> larger in future so I don't think fetching from git will be a good solution >> >>> for gcc ever. >> >> >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. >> > >> > I did not check if the fetcher has this support but it would be a >> > nice solution. >> >> Shallow clones won't be able to support SRCREV properly, as you can >> only clone shallowly from HEAD, not from an arbitrary point in >> history, AFAIK. > > Right, shallow clones are a can of worms from a variety of angles. > > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher > which: > > a) Generates tarballs of single git revisions if tarball generation is > turned on > b) Searches for single revision tarballs before trying the main checkout > approach. > > This would mean that WORKDIR may or may not have a .git directory for > any SRC_URI marked with this. I think we should all be able to live with > that and it shouldn't break too much? We'll end with multiple tarballs, aren't we? -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn @ 2012-09-14 12:36 ` Otavio Salvador 0 siblings, 0 replies; 29+ messages in thread From: Otavio Salvador @ 2012-09-14 12:36 UTC (permalink / raw) To: Richard Purdie; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador >> <otavio@ossystems.com.br> wrote: >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: >> >> Khem Raj wrote: >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become >> >>> larger in future so I don't think fetching from git will be a good solution >> >>> for gcc ever. >> >> >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. >> > >> > I did not check if the fetcher has this support but it would be a >> > nice solution. >> >> Shallow clones won't be able to support SRCREV properly, as you can >> only clone shallowly from HEAD, not from an arbitrary point in >> history, AFAIK. > > Right, shallow clones are a can of worms from a variety of angles. > > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher > which: > > a) Generates tarballs of single git revisions if tarball generation is > turned on > b) Searches for single revision tarballs before trying the main checkout > approach. > > This would mean that WORKDIR may or may not have a .git directory for > any SRC_URI marked with this. I think we should all be able to live with > that and it shouldn't break too much? We'll end with multiple tarballs, aren't we? -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-14 12:36 ` Otavio Salvador @ 2012-09-14 13:23 ` Richard Purdie -1 siblings, 0 replies; 29+ messages in thread From: Richard Purdie @ 2012-09-14 13:23 UTC (permalink / raw) To: Otavio Salvador; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: > On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: > >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador > >> <otavio@ossystems.com.br> wrote: > >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: > >> >> Khem Raj wrote: > >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become > >> >>> larger in future so I don't think fetching from git will be a good solution > >> >>> for gcc ever. > >> >> > >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. > >> > > >> > I did not check if the fetcher has this support but it would be a > >> > nice solution. > >> > >> Shallow clones won't be able to support SRCREV properly, as you can > >> only clone shallowly from HEAD, not from an arbitrary point in > >> history, AFAIK. > > > > Right, shallow clones are a can of worms from a variety of angles. > > > > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher > > which: > > > > a) Generates tarballs of single git revisions if tarball generation is > > turned on > > b) Searches for single revision tarballs before trying the main checkout > > approach. > > > > This would mean that WORKDIR may or may not have a .git directory for > > any SRC_URI marked with this. I think we should all be able to live with > > that and it shouldn't break too much? > > We'll end with multiple tarballs, aren't we? Yes. I'm not seeing that as a big problem for most of the usecases where we'd use this feature. You could skip shipping the big tarball of the whole repo at distribution time. Cheers, Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn @ 2012-09-14 13:23 ` Richard Purdie 0 siblings, 0 replies; 29+ messages in thread From: Richard Purdie @ 2012-09-14 13:23 UTC (permalink / raw) To: Otavio Salvador; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: > On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: > >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador > >> <otavio@ossystems.com.br> wrote: > >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: > >> >> Khem Raj wrote: > >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become > >> >>> larger in future so I don't think fetching from git will be a good solution > >> >>> for gcc ever. > >> >> > >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. > >> > > >> > I did not check if the fetcher has this support but it would be a > >> > nice solution. > >> > >> Shallow clones won't be able to support SRCREV properly, as you can > >> only clone shallowly from HEAD, not from an arbitrary point in > >> history, AFAIK. > > > > Right, shallow clones are a can of worms from a variety of angles. > > > > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher > > which: > > > > a) Generates tarballs of single git revisions if tarball generation is > > turned on > > b) Searches for single revision tarballs before trying the main checkout > > approach. > > > > This would mean that WORKDIR may or may not have a .git directory for > > any SRC_URI marked with this. I think we should all be able to live with > > that and it shouldn't break too much? > > We'll end with multiple tarballs, aren't we? Yes. I'm not seeing that as a big problem for most of the usecases where we'd use this feature. You could skip shipping the big tarball of the whole repo at distribution time. Cheers, Richard ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-14 13:23 ` Richard Purdie @ 2012-09-14 13:25 ` Otavio Salvador -1 siblings, 0 replies; 29+ messages in thread From: Otavio Salvador @ 2012-09-14 13:25 UTC (permalink / raw) To: Richard Purdie; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: >> On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie >> <richard.purdie@linuxfoundation.org> wrote: >> > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: >> >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador >> >> <otavio@ossystems.com.br> wrote: >> >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: >> >> >> Khem Raj wrote: >> >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become >> >> >>> larger in future so I don't think fetching from git will be a good solution >> >> >>> for gcc ever. >> >> >> >> >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. >> >> > >> >> > I did not check if the fetcher has this support but it would be a >> >> > nice solution. >> >> >> >> Shallow clones won't be able to support SRCREV properly, as you can >> >> only clone shallowly from HEAD, not from an arbitrary point in >> >> history, AFAIK. >> > >> > Right, shallow clones are a can of worms from a variety of angles. >> > >> > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher >> > which: >> > >> > a) Generates tarballs of single git revisions if tarball generation is >> > turned on >> > b) Searches for single revision tarballs before trying the main checkout >> > approach. >> > >> > This would mean that WORKDIR may or may not have a .git directory for >> > any SRC_URI marked with this. I think we should all be able to live with >> > that and it shouldn't break too much? >> >> We'll end with multiple tarballs, aren't we? > > Yes. I'm not seeing that as a big problem for most of the usecases where > we'd use this feature. You could skip shipping the big tarball of the > whole repo at distribution time. By the way, there're any tool to clean the repo? (as we do for sstate-cache)? -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/4] gcc: Switch SRC_URI to use svn @ 2012-09-14 13:25 ` Otavio Salvador 0 siblings, 0 replies; 29+ messages in thread From: Otavio Salvador @ 2012-09-14 13:25 UTC (permalink / raw) To: Richard Purdie; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: >> On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie >> <richard.purdie@linuxfoundation.org> wrote: >> > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: >> >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador >> >> <otavio@ossystems.com.br> wrote: >> >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: >> >> >> Khem Raj wrote: >> >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become >> >> >>> larger in future so I don't think fetching from git will be a good solution >> >> >>> for gcc ever. >> >> >> >> >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. >> >> > >> >> > I did not check if the fetcher has this support but it would be a >> >> > nice solution. >> >> >> >> Shallow clones won't be able to support SRCREV properly, as you can >> >> only clone shallowly from HEAD, not from an arbitrary point in >> >> history, AFAIK. >> > >> > Right, shallow clones are a can of worms from a variety of angles. >> > >> > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher >> > which: >> > >> > a) Generates tarballs of single git revisions if tarball generation is >> > turned on >> > b) Searches for single revision tarballs before trying the main checkout >> > approach. >> > >> > This would mean that WORKDIR may or may not have a .git directory for >> > any SRC_URI marked with this. I think we should all be able to live with >> > that and it shouldn't break too much? >> >> We'll end with multiple tarballs, aren't we? > > Yes. I'm not seeing that as a big problem for most of the usecases where > we'd use this feature. You could skip shipping the big tarball of the > whole repo at distribution time. By the way, there're any tool to clean the repo? (as we do for sstate-cache)? -- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-14 13:25 ` Otavio Salvador @ 2012-09-14 18:30 ` McClintock Matthew-B29882 -1 siblings, 0 replies; 29+ messages in thread From: McClintock Matthew-B29882 @ 2012-09-14 18:30 UTC (permalink / raw) To: Otavio Salvador; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, Sep 14, 2012 at 8:25 AM, Otavio Salvador <otavio@ossystems.com.br> wrote: > On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: >> On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: >>> On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie >>> <richard.purdie@linuxfoundation.org> wrote: >>> > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: >>> >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador >>> >> <otavio@ossystems.com.br> wrote: >>> >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: >>> >> >> Khem Raj wrote: >>> >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become >>> >> >>> larger in future so I don't think fetching from git will be a good solution >>> >> >>> for gcc ever. >>> >> >> >>> >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. >>> >> > >>> >> > I did not check if the fetcher has this support but it would be a >>> >> > nice solution. >>> >> >>> >> Shallow clones won't be able to support SRCREV properly, as you can >>> >> only clone shallowly from HEAD, not from an arbitrary point in >>> >> history, AFAIK. >>> > >>> > Right, shallow clones are a can of worms from a variety of angles. >>> > >>> > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher >>> > which: >>> > >>> > a) Generates tarballs of single git revisions if tarball generation is >>> > turned on >>> > b) Searches for single revision tarballs before trying the main checkout >>> > approach. >>> > >>> > This would mean that WORKDIR may or may not have a .git directory for >>> > any SRC_URI marked with this. I think we should all be able to live with >>> > that and it shouldn't break too much? >>> >>> We'll end with multiple tarballs, aren't we? >> >> Yes. I'm not seeing that as a big problem for most of the usecases where >> we'd use this feature. You could skip shipping the big tarball of the >> whole repo at distribution time. > > By the way, there're any tool to clean the repo? (as we do for sstate-cache)? scripts/clean-workdir cleans tmp/ - not sure about downloads -M > > -- > Otavio Salvador O.S. Systems > E-mail: otavio@ossystems.com.br http://www.ossystems.com.br > Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br > > _______________________________________________ > bitbake-devel mailing list > bitbake-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitbake-devel] [PATCH 1/4] gcc: Switch SRC_URI to use svn @ 2012-09-14 18:30 ` McClintock Matthew-B29882 0 siblings, 0 replies; 29+ messages in thread From: McClintock Matthew-B29882 @ 2012-09-14 18:30 UTC (permalink / raw) To: Otavio Salvador; +Cc: Chris Larson, bitbake-devel, openembedded-core On Fri, Sep 14, 2012 at 8:25 AM, Otavio Salvador <otavio@ossystems.com.br> wrote: > On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: >> On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: >>> On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie >>> <richard.purdie@linuxfoundation.org> wrote: >>> > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: >>> >> On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador >>> >> <otavio@ossystems.com.br> wrote: >>> >> > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: >>> >> >> Khem Raj wrote: >>> >> >>> I agree but then 1.7 GB is noticeably huge too and it will only become >>> >> >>> larger in future so I don't think fetching from git will be a good solution >>> >> >>> for gcc ever. >>> >> >> >>> >> >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. >>> >> > >>> >> > I did not check if the fetcher has this support but it would be a >>> >> > nice solution. >>> >> >>> >> Shallow clones won't be able to support SRCREV properly, as you can >>> >> only clone shallowly from HEAD, not from an arbitrary point in >>> >> history, AFAIK. >>> > >>> > Right, shallow clones are a can of worms from a variety of angles. >>> > >>> > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher >>> > which: >>> > >>> > a) Generates tarballs of single git revisions if tarball generation is >>> > turned on >>> > b) Searches for single revision tarballs before trying the main checkout >>> > approach. >>> > >>> > This would mean that WORKDIR may or may not have a .git directory for >>> > any SRC_URI marked with this. I think we should all be able to live with >>> > that and it shouldn't break too much? >>> >>> We'll end with multiple tarballs, aren't we? >> >> Yes. I'm not seeing that as a big problem for most of the usecases where >> we'd use this feature. You could skip shipping the big tarball of the >> whole repo at distribution time. > > By the way, there're any tool to clean the repo? (as we do for sstate-cache)? scripts/clean-workdir cleans tmp/ - not sure about downloads -M > > -- > Otavio Salvador O.S. Systems > E-mail: otavio@ossystems.com.br http://www.ossystems.com.br > Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br > > _______________________________________________ > bitbake-devel mailing list > bitbake-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH 1/4] gcc: Switch SRC_URI to use svn 2012-09-14 11:58 ` Richard Purdie @ 2012-09-15 6:25 ` Martin Jansa -1 siblings, 0 replies; 29+ messages in thread From: Martin Jansa @ 2012-09-15 6:25 UTC (permalink / raw) To: Richard Purdie Cc: Chris Larson, bitbake-devel, Otavio Salvador, openembedded-core [-- Attachment #1: Type: text/plain, Size: 1844 bytes --] On Fri, Sep 14, 2012 at 12:58:28PM +0100, Richard Purdie wrote: > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: > > On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador > > <otavio@ossystems.com.br> wrote: > > > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: > > >> Khem Raj wrote: > > >>> I agree but then 1.7 GB is noticeably huge too and it will only become > > >>> larger in future so I don't think fetching from git will be a good solution > > >>> for gcc ever. > > >> > > >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. > > > > > > I did not check if the fetcher has this support but it would be a > > > nice solution. > > > > Shallow clones won't be able to support SRCREV properly, as you can > > only clone shallowly from HEAD, not from an arbitrary point in > > history, AFAIK. > > Right, shallow clones are a can of worms from a variety of angles. > > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher > which: > > a) Generates tarballs of single git revisions if tarball generation is > turned on > b) Searches for single revision tarballs before trying the main checkout > approach. > > This would mean that WORKDIR may or may not have a .git directory for > any SRC_URI marked with this. I think we should all be able to live with > that and it shouldn't break too much? Ah so finally fetch2 will have same functionality like fetch11 had? IIRC there is old buq report about this. > > Cheers, > > Richard > > > > _______________________________________________ > bitbake-devel mailing list > bitbake-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitbake-devel] [PATCH 1/4] gcc: Switch SRC_URI to use svn @ 2012-09-15 6:25 ` Martin Jansa 0 siblings, 0 replies; 29+ messages in thread From: Martin Jansa @ 2012-09-15 6:25 UTC (permalink / raw) To: Richard Purdie; +Cc: Chris Larson, bitbake-devel, openembedded-core [-- Attachment #1: Type: text/plain, Size: 1844 bytes --] On Fri, Sep 14, 2012 at 12:58:28PM +0100, Richard Purdie wrote: > On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: > > On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador > > <otavio@ossystems.com.br> wrote: > > > On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg <bjst@enea.com> wrote: > > >> Khem Raj wrote: > > >>> I agree but then 1.7 GB is noticeably huge too and it will only become > > >>> larger in future so I don't think fetching from git will be a good solution > > >>> for gcc ever. > > >> > > >> Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. > > > > > > I did not check if the fetcher has this support but it would be a > > > nice solution. > > > > Shallow clones won't be able to support SRCREV properly, as you can > > only clone shallowly from HEAD, not from an arbitrary point in > > history, AFAIK. > > Right, shallow clones are a can of worms from a variety of angles. > > My current thinking is a ;allowsinglerev=1 parameter to the git fetcher > which: > > a) Generates tarballs of single git revisions if tarball generation is > turned on > b) Searches for single revision tarballs before trying the main checkout > approach. > > This would mean that WORKDIR may or may not have a .git directory for > any SRC_URI marked with this. I think we should all be able to live with > that and it shouldn't break too much? Ah so finally fetch2 will have same functionality like fetch11 had? IIRC there is old buq report about this. > > Cheers, > > Richard > > > > _______________________________________________ > bitbake-devel mailing list > bitbake-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 2/4] gcc-4.7: Fix build for armv4/EABI and ppc/Os 2012-09-06 4:35 [PATCH 0/4] GCC fixes and updates Khem Raj 2012-09-06 4:35 ` [PATCH 1/4] gcc: Switch SRC_URI to use svn Khem Raj @ 2012-09-06 4:35 ` Khem Raj 2012-09-06 7:04 ` Koen Kooi 2012-09-06 4:35 ` [PATCH 3/4] arch-armv4.inc: On armv4 add --fix-v4bx to linker flags for kernel Khem Raj ` (3 subsequent siblings) 5 siblings, 1 reply; 29+ messages in thread From: Khem Raj @ 2012-09-06 4:35 UTC (permalink / raw) To: openembedded-core arm patch is a forward port from OE/classic ppc patch should help in building images with Os Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-devtools/gcc/gcc-4.7.inc | 4 ++- .../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch | 29 ++++++++++++++++++++ .../gcc/gcc-4.7/ppc_no_crtsavres.patch | 21 ++++++++++++++ 3 files changed, 53 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc index affbd54..b455b28 100644 --- a/meta/recipes-devtools/gcc/gcc-4.7.inc +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc @@ -1,6 +1,6 @@ require gcc-common.inc -PR = "r11" +PR = "r12" # Third digit in PV should be incremented after a minor release # happens from this branch on gcc e.g. currently its 4.7.1 @@ -75,6 +75,8 @@ SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};protocol=http \ file://fix-g++-sysroot.patch \ file://disablesdt.patch \ file://libtool.patch \ + file://gcc-armv4-pass-fix-v4bx-to-ld.patch \ + file://ppc_no_crtsavres.patch \ " S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${BRANCH}" diff --git a/meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch b/meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch new file mode 100644 index 0000000..6cd645a --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch @@ -0,0 +1,29 @@ +The LINK_SPEC for linux gets overwritten by linux-eabi.h which +means the value of TARGET_FIX_V4BX_SPEC gets lost and as a result +the option is not passed to linker when chosing march=armv4 +This patch redefines this in linux-eabi.h and reinserts it +for eabi defaulting toolchains. + +We might want to send it upstream + +-Khem +Index: gcc-4_7-branch/gcc/config/arm/linux-eabi.h +=================================================================== +--- gcc-4_7-branch.orig/gcc/config/arm/linux-eabi.h 2012-08-21 22:54:12.448453417 -0700 ++++ gcc-4_7-branch/gcc/config/arm/linux-eabi.h 2012-08-21 23:05:18.008478722 -0700 +@@ -78,10 +78,14 @@ + %{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \ + %{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}" + ++/* For armv4 we pass --fix-v4bx to linker to support EABI */ ++#undef TARGET_FIX_V4BX_SPEC ++#define TARGET_FIX_V4BX_SPEC "%{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4: --fix-v4bx}" ++ + /* At this point, bpabi.h will have clobbered LINK_SPEC. We want to + use the GNU/Linux version, not the generic BPABI version. */ + #undef LINK_SPEC +-#define LINK_SPEC BE8_LINK_SPEC \ ++#define LINK_SPEC BE8_LINK_SPEC TARGET_FIX_V4BX_SPEC \ + LINUX_OR_ANDROID_LD (LINUX_TARGET_LINK_SPEC, \ + LINUX_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) + diff --git a/meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch b/meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch new file mode 100644 index 0000000..88684d3 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch @@ -0,0 +1,21 @@ +--- a/gcc/config/rs6000/sysv4.h ++++ b/gcc/config/rs6000/sysv4.h +@@ -246,13 +246,13 @@ do { \ + + /* Define cutoff for using external functions to save floating point. + When optimizing for size, use external functions when profitable. */ +-#define FP_SAVE_INLINE(FIRST_REG) (optimize_size \ ++#define FP_SAVE_INLINE(FIRST_REG) (1 || (optimize_size \ + ? ((FIRST_REG) == 62 \ + || (FIRST_REG) == 63) \ +- : (FIRST_REG) < 64) ++ : (FIRST_REG) < 64)) + /* And similarly for general purpose registers. */ +-#define GP_SAVE_INLINE(FIRST_REG) ((FIRST_REG) < 32 \ +- && !optimize_size) ++#define GP_SAVE_INLINE(FIRST_REG) (1 || ((FIRST_REG) < 32 \ ++ && !optimize_size)) + + /* Put jump tables in read-only memory, rather than in .text. */ + #define JUMP_TABLES_IN_TEXT_SECTION 0 + -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 2/4] gcc-4.7: Fix build for armv4/EABI and ppc/Os 2012-09-06 4:35 ` [PATCH 2/4] gcc-4.7: Fix build for armv4/EABI and ppc/Os Khem Raj @ 2012-09-06 7:04 ` Koen Kooi 0 siblings, 0 replies; 29+ messages in thread From: Koen Kooi @ 2012-09-06 7:04 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core Op 6 sep. 2012, om 06:35 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven: > arm patch is a forward port from OE/classic > ppc patch should help in building images with Os Can you add an Upstream-Status to both patches? > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > --- > meta/recipes-devtools/gcc/gcc-4.7.inc | 4 ++- > .../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch | 29 ++++++++++++++++++++ > .../gcc/gcc-4.7/ppc_no_crtsavres.patch | 21 ++++++++++++++ > 3 files changed, 53 insertions(+), 1 deletion(-) > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch > > diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc > index affbd54..b455b28 100644 > --- a/meta/recipes-devtools/gcc/gcc-4.7.inc > +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc > @@ -1,6 +1,6 @@ > require gcc-common.inc > > -PR = "r11" > +PR = "r12" > > # Third digit in PV should be incremented after a minor release > # happens from this branch on gcc e.g. currently its 4.7.1 > @@ -75,6 +75,8 @@ SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};protocol=http \ > file://fix-g++-sysroot.patch \ > file://disablesdt.patch \ > file://libtool.patch \ > + file://gcc-armv4-pass-fix-v4bx-to-ld.patch \ > + file://ppc_no_crtsavres.patch \ > " > > S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${BRANCH}" > diff --git a/meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch b/meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch > new file mode 100644 > index 0000000..6cd645a > --- /dev/null > +++ b/meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch > @@ -0,0 +1,29 @@ > +The LINK_SPEC for linux gets overwritten by linux-eabi.h which > +means the value of TARGET_FIX_V4BX_SPEC gets lost and as a result > +the option is not passed to linker when chosing march=armv4 > +This patch redefines this in linux-eabi.h and reinserts it > +for eabi defaulting toolchains. > + > +We might want to send it upstream > + > +-Khem > +Index: gcc-4_7-branch/gcc/config/arm/linux-eabi.h > +=================================================================== > +--- gcc-4_7-branch.orig/gcc/config/arm/linux-eabi.h 2012-08-21 22:54:12.448453417 -0700 > ++++ gcc-4_7-branch/gcc/config/arm/linux-eabi.h 2012-08-21 23:05:18.008478722 -0700 > +@@ -78,10 +78,14 @@ > + %{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \ > + %{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}" > + > ++/* For armv4 we pass --fix-v4bx to linker to support EABI */ > ++#undef TARGET_FIX_V4BX_SPEC > ++#define TARGET_FIX_V4BX_SPEC "%{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4: --fix-v4bx}" > ++ > + /* At this point, bpabi.h will have clobbered LINK_SPEC. We want to > + use the GNU/Linux version, not the generic BPABI version. */ > + #undef LINK_SPEC > +-#define LINK_SPEC BE8_LINK_SPEC \ > ++#define LINK_SPEC BE8_LINK_SPEC TARGET_FIX_V4BX_SPEC \ > + LINUX_OR_ANDROID_LD (LINUX_TARGET_LINK_SPEC, \ > + LINUX_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) > + > diff --git a/meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch b/meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch > new file mode 100644 > index 0000000..88684d3 > --- /dev/null > +++ b/meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch > @@ -0,0 +1,21 @@ > +--- a/gcc/config/rs6000/sysv4.h > ++++ b/gcc/config/rs6000/sysv4.h > +@@ -246,13 +246,13 @@ do { \ > + > + /* Define cutoff for using external functions to save floating point. > + When optimizing for size, use external functions when profitable. */ > +-#define FP_SAVE_INLINE(FIRST_REG) (optimize_size \ > ++#define FP_SAVE_INLINE(FIRST_REG) (1 || (optimize_size \ > + ? ((FIRST_REG) == 62 \ > + || (FIRST_REG) == 63) \ > +- : (FIRST_REG) < 64) > ++ : (FIRST_REG) < 64)) > + /* And similarly for general purpose registers. */ > +-#define GP_SAVE_INLINE(FIRST_REG) ((FIRST_REG) < 32 \ > +- && !optimize_size) > ++#define GP_SAVE_INLINE(FIRST_REG) (1 || ((FIRST_REG) < 32 \ > ++ && !optimize_size)) > + > + /* Put jump tables in read-only memory, rather than in .text. */ > + #define JUMP_TABLES_IN_TEXT_SECTION 0 > + > -- > 1.7.9.5 > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 3/4] arch-armv4.inc: On armv4 add --fix-v4bx to linker flags for kernel 2012-09-06 4:35 [PATCH 0/4] GCC fixes and updates Khem Raj 2012-09-06 4:35 ` [PATCH 1/4] gcc: Switch SRC_URI to use svn Khem Raj 2012-09-06 4:35 ` [PATCH 2/4] gcc-4.7: Fix build for armv4/EABI and ppc/Os Khem Raj @ 2012-09-06 4:35 ` Khem Raj 2012-09-06 4:35 ` [PATCH 4/4] gcc-4.7: Backport libgcc fixes to appease the new build sequence Khem Raj ` (2 subsequent siblings) 5 siblings, 0 replies; 29+ messages in thread From: Khem Raj @ 2012-09-06 4:35 UTC (permalink / raw) To: openembedded-core Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/conf/machine/include/arm/arch-armv4.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc index a09c323..cb747ac 100644 --- a/meta/conf/machine/include/arm/arch-armv4.inc +++ b/meta/conf/machine/include/arm/arch-armv4.inc @@ -4,6 +4,7 @@ ARMPKGARCH ?= "armv4" TUNEVALID[armv4] = "Enable instructions for ARMv4" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}" +TARGET_LD_KERNEL_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "--fix-v4bx", "", d)}" MACHINEOVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "armv4", ":armv4", "" ,d)}" require conf/machine/include/arm/arch-arm.inc -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [PATCH 4/4] gcc-4.7: Backport libgcc fixes to appease the new build sequence 2012-09-06 4:35 [PATCH 0/4] GCC fixes and updates Khem Raj ` (2 preceding siblings ...) 2012-09-06 4:35 ` [PATCH 3/4] arch-armv4.inc: On armv4 add --fix-v4bx to linker flags for kernel Khem Raj @ 2012-09-06 4:35 ` Khem Raj 2012-09-09 6:02 ` [PATCH 0/4] GCC fixes and updates Khem Raj 2012-09-12 17:43 ` Saul Wold 5 siblings, 0 replies; 29+ messages in thread From: Khem Raj @ 2012-09-06 4:35 UTC (permalink / raw) To: openembedded-core This makes the libgcc builds identical when done with gcc-cross-initial or final gcc-cross. Since eglibc only sees gcc-cross-initial it is important that the final libgcc that appears on root file system is same as the one against which eglibc was built. Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-devtools/gcc/gcc-4.7.inc | 4 +- ...-vis_hide-gen-hide-list-Do-not-make-defin.patch | 93 ++++++++++++++++++++ ...USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch | 49 +++++++++++ 3 files changed, 145 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc index b455b28..d8e6421 100644 --- a/meta/recipes-devtools/gcc/gcc-4.7.inc +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc @@ -1,6 +1,6 @@ require gcc-common.inc -PR = "r12" +PR = "r13" # Third digit in PV should be incremented after a minor release # happens from this branch on gcc e.g. currently its 4.7.1 @@ -77,6 +77,8 @@ SRC_URI = "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};protocol=http \ file://libtool.patch \ file://gcc-armv4-pass-fix-v4bx-to-ld.patch \ file://ppc_no_crtsavres.patch \ + file://0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch \ + file://0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch \ " S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${BRANCH}" diff --git a/meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch b/meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch new file mode 100644 index 0000000..b6f8f94 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch @@ -0,0 +1,93 @@ +From b78f422ee83d279a83c62491b252cfec5b94e92a Mon Sep 17 00:00:00 2001 +From: jsm28 <jsm28@138bc75d-0d04-0410-961f-82ee72b054a4> +Date: Wed, 22 Aug 2012 08:36:23 +0000 +Subject: [PATCH] * Makefile.in (vis_hide, gen-hide-list): Do not make + definitions depend on --enable-shared. + ($(lib1asmfuncs-o)): Use %.vis files independent of + --enable-shared. * static-object.mk + ($(base)$(objext), $(base).vis) + ($(base)_s$(objext)): Use same rules for visibility + handling as in shared-object.mk. + +git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@190588 138bc75d-0d04-0410-961f-82ee72b054a4 +--- + libgcc/ChangeLog | 10 ++++++++++ + libgcc/Makefile.in | 16 ++++------------ + libgcc/static-object.mk | 10 ++++++++-- + 3 files changed, 22 insertions(+), 14 deletions(-) + +Upstream-Status: Backport + +-Khem +05-Sep-2012 + +Index: gcc-4_7-branch/libgcc/Makefile.in +=================================================================== +--- gcc-4_7-branch.orig/libgcc/Makefile.in 2012-08-21 22:33:20.000000000 -0700 ++++ gcc-4_7-branch/libgcc/Makefile.in 2012-09-05 17:30:28.572998745 -0700 +@@ -362,6 +362,7 @@ + ifneq ($(LIBUNWIND),) + install-libunwind = install-libunwind + endif ++endif + + # For -fvisibility=hidden. We need both a -fvisibility=hidden on + # the command line, and a #define to prevent libgcc2.h etc from +@@ -385,11 +386,8 @@ + gen-hide-list = echo > $@ + endif + +-else +-# Not enable_shared. ++ifneq ($(enable_shared),yes) + iterator = $(srcdir)/empty.mk $(patsubst %,$(srcdir)/static-object.mk,$(iter-items)) +-vis_hide = +-gen-hide-list = echo > \$@ + endif + + LIB2ADD += enable-execute-stack.c +@@ -438,7 +436,6 @@ + $(LIB2_DIVMOD_FUNCS)) + + # Build "libgcc1" (assembly) components. +-ifeq ($(enable_shared),yes) + + lib1asmfuncs-o = $(patsubst %,%$(objext),$(LIB1ASMFUNCS)) + $(lib1asmfuncs-o): %$(objext): $(srcdir)/config/$(LIB1ASMSRC) %.vis +@@ -450,14 +447,9 @@ + lib1asmfuncs-s-o = $(patsubst %,%_s$(objext),$(LIB1ASMFUNCS)) + $(lib1asmfuncs-s-o): %_s$(objext): $(srcdir)/config/$(LIB1ASMSRC) + $(gcc_s_compile) -DL$* -xassembler-with-cpp -c $< +-libgcc-s-objects += $(lib1asmfuncs-s-o) +- +-else ++ifeq ($(enable_shared),yes) + +-lib1asmfuncs-o = $(patsubst %,%$(objext),$(LIB1ASMFUNCS)) +-$(lib1asmfuncs-o): %$(objext): $(srcdir)/config/$(LIB1ASMSRC) +- $(gcc_compile) -DL$* -xassembler-with-cpp -c $< +-libgcc-objects += $(lib1asmfuncs-o) ++libgcc-s-objects += $(lib1asmfuncs-s-o) + + endif + +Index: gcc-4_7-branch/libgcc/static-object.mk +=================================================================== +--- gcc-4_7-branch.orig/libgcc/static-object.mk 2012-08-21 22:33:20.000000000 -0700 ++++ gcc-4_7-branch/libgcc/static-object.mk 2012-09-05 17:30:28.572998745 -0700 +@@ -24,7 +24,13 @@ + endif + endif + +-$(base)$(objext): $o +- $(gcc_compile) -c -xassembler-with-cpp $< ++$(base)$(objext): $o $(base).vis ++ $(gcc_compile) -c -xassembler-with-cpp -include $*.vis $< ++ ++$(base).vis: $(base)_s$(objext) ++ $(gen-hide-list) ++ ++$(base)_s$(objext): $o ++ $(gcc_s_compile) -c -xassembler-with-cpp $< + + endif diff --git a/meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch b/meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch new file mode 100644 index 0000000..15034f7 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch @@ -0,0 +1,49 @@ +From 935475158f45b9c55a54647543c0402b4b3043ae Mon Sep 17 00:00:00 2001 +From: jsm28 <jsm28@138bc75d-0d04-0410-961f-82ee72b054a4> +Date: Sun, 19 Aug 2012 15:11:40 +0000 +Subject: [PATCH] * crtstuff.c (USE_PT_GNU_EH_FRAME): Define for + systems using glibc even if inhibit_libc. + +git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@190517 138bc75d-0d04-0410-961f-82ee72b054a4 +--- + libgcc/ChangeLog | 5 +++++ + libgcc/crtstuff.c | 16 +++++++++++++++- + 2 files changed, 20 insertions(+), 1 deletion(-) + +Upstream-Status: Backport + +-Khem 05-Sep-2012 +Index: gcc-4_7-branch/libgcc/crtstuff.c +=================================================================== +--- gcc-4_7-branch.orig/libgcc/crtstuff.c 2012-08-21 22:33:20.000000000 -0700 ++++ gcc-4_7-branch/libgcc/crtstuff.c 2012-09-05 17:28:49.248994968 -0700 +@@ -1,7 +1,7 @@ + /* Specialized bits of code needed to support construction and + destruction of file-scope objects in C++ code. + Copyright (C) 1991, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 +- 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2010, 2011 ++ 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2010, 2011, 2012 + Free Software Foundation, Inc. + Contributed by Ron Guilmette (rfg@monkeys.com). + +@@ -113,6 +113,20 @@ + # define USE_PT_GNU_EH_FRAME + # endif + #endif ++ ++#if defined(OBJECT_FORMAT_ELF) \ ++ && !defined(OBJECT_FORMAT_FLAT) \ ++ && defined(HAVE_LD_EH_FRAME_HDR) \ ++ && !defined(CRTSTUFFT_O) \ ++ && defined(inhibit_libc) \ ++ && (defined(__GLIBC__) || defined(__gnu_linux__) || defined(__GNU__)) ++/* On systems using glibc, an inhibit_libc build of libgcc is only ++ part of a bootstrap process. Build the same crt*.o as would be ++ built with headers present, so that it is not necessary to build ++ glibc more than once for the bootstrap to converge. */ ++# define USE_PT_GNU_EH_FRAME ++#endif ++ + #if defined(EH_FRAME_SECTION_NAME) && !defined(USE_PT_GNU_EH_FRAME) + # define USE_EH_FRAME_REGISTRY + #endif -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 0/4] GCC fixes and updates 2012-09-06 4:35 [PATCH 0/4] GCC fixes and updates Khem Raj ` (3 preceding siblings ...) 2012-09-06 4:35 ` [PATCH 4/4] gcc-4.7: Backport libgcc fixes to appease the new build sequence Khem Raj @ 2012-09-09 6:02 ` Khem Raj 2012-09-12 17:43 ` Saul Wold 5 siblings, 0 replies; 29+ messages in thread From: Khem Raj @ 2012-09-09 6:02 UTC (permalink / raw) To: openembedded-core On Wed, Sep 5, 2012 at 9:35 PM, Khem Raj <raj.khem@gmail.com> wrote: > This patchset switches us back to using svn for SRC_URI > and fixes building for armv4 and ppc soft float targets > Finally fixes for libgcc to build with new build sequence > such that its same with gcc-cross and gcc-cross-initial > I have pushed update to this patchset 1. Add upstream status to new patches 2. Replace the ppc Os hack patch with upstream back port > The following changes since commit 610f8c0c0cab8e258919689fd641faec28b58caf: > > adt-installer: Allow changing YOCTOADT_REPO (2012-09-05 23:27:31 +0100) > > are available in the git repository at: > > git://git.openembedded.org/openembedded-core-contrib kraj/gcc-updates > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/gcc-updates > > Khem Raj (4): > gcc: Switch SRC_URI to use svn > gcc-4.7: Fix build for armv4/EABI and ppc/Os > arch-armv4.inc: On armv4 add --fix-v4bx to linker flags for kernel > gcc-4.7: Backport libgcc fixes to appease the new build sequence > > meta/conf/machine/include/arm/arch-armv4.inc | 1 + > meta/recipes-devtools/gcc/gcc-4.7.inc | 14 +-- > ...-vis_hide-gen-hide-list-Do-not-make-defin.patch | 93 ++++++++++++++++++++ > ...USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch | 49 +++++++++++ > .../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch | 29 ++++++ > .../gcc/gcc-4.7/ppc_no_crtsavres.patch | 21 +++++ > 6 files changed, 202 insertions(+), 5 deletions(-) > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch > > -- > 1.7.9.5 > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 0/4] GCC fixes and updates 2012-09-06 4:35 [PATCH 0/4] GCC fixes and updates Khem Raj ` (4 preceding siblings ...) 2012-09-09 6:02 ` [PATCH 0/4] GCC fixes and updates Khem Raj @ 2012-09-12 17:43 ` Saul Wold 5 siblings, 0 replies; 29+ messages in thread From: Saul Wold @ 2012-09-12 17:43 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On 09/05/2012 09:35 PM, Khem Raj wrote: > This patchset switches us back to using svn for SRC_URI > and fixes building for armv4 and ppc soft float targets > Finally fixes for libgcc to build with new build sequence > such that its same with gcc-cross and gcc-cross-initial > > The following changes since commit 610f8c0c0cab8e258919689fd641faec28b58caf: > > adt-installer: Allow changing YOCTOADT_REPO (2012-09-05 23:27:31 +0100) > > are available in the git repository at: > > git://git.openembedded.org/openembedded-core-contrib kraj/gcc-updates > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/gcc-updates > > Khem Raj (4): > gcc: Switch SRC_URI to use svn There has already been some discussion about this one. > gcc-4.7: Fix build for armv4/EABI and ppc/Os > arch-armv4.inc: On armv4 add --fix-v4bx to linker flags for kernel > gcc-4.7: Backport libgcc fixes to appease the new build sequence > Merged these last three into OE-Core Thanks Sau! > meta/conf/machine/include/arm/arch-armv4.inc | 1 + > meta/recipes-devtools/gcc/gcc-4.7.inc | 14 +-- > ...-vis_hide-gen-hide-list-Do-not-make-defin.patch | 93 ++++++++++++++++++++ > ...USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch | 49 +++++++++++ > .../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch | 29 ++++++ > .../gcc/gcc-4.7/ppc_no_crtsavres.patch | 21 +++++ > 6 files changed, 202 insertions(+), 5 deletions(-) > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch > create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch > ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2012-09-15 6:38 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-09-06 4:35 [PATCH 0/4] GCC fixes and updates Khem Raj 2012-09-06 4:35 ` [PATCH 1/4] gcc: Switch SRC_URI to use svn Khem Raj 2012-09-06 7:05 ` Koen Kooi 2012-09-12 2:44 ` Gary Thomas 2012-09-12 14:08 ` Richard Purdie 2012-09-12 15:34 ` Khem Raj 2012-09-13 12:19 ` Björn Stenberg 2012-09-13 13:06 ` Otavio Salvador 2012-09-13 14:22 ` Chris Larson 2012-09-14 11:58 ` [OE-core] " Richard Purdie 2012-09-14 11:58 ` Richard Purdie 2012-09-14 12:31 ` [OE-core] " Bruce Ashfield 2012-09-14 12:31 ` Bruce Ashfield 2012-09-14 12:36 ` [OE-core] " Otavio Salvador 2012-09-14 12:36 ` Otavio Salvador 2012-09-14 13:23 ` [OE-core] " Richard Purdie 2012-09-14 13:23 ` Richard Purdie 2012-09-14 13:25 ` [OE-core] " Otavio Salvador 2012-09-14 13:25 ` Otavio Salvador 2012-09-14 18:30 ` [OE-core] " McClintock Matthew-B29882 2012-09-14 18:30 ` [bitbake-devel] " McClintock Matthew-B29882 2012-09-15 6:25 ` [OE-core] " Martin Jansa 2012-09-15 6:25 ` [bitbake-devel] " Martin Jansa 2012-09-06 4:35 ` [PATCH 2/4] gcc-4.7: Fix build for armv4/EABI and ppc/Os Khem Raj 2012-09-06 7:04 ` Koen Kooi 2012-09-06 4:35 ` [PATCH 3/4] arch-armv4.inc: On armv4 add --fix-v4bx to linker flags for kernel Khem Raj 2012-09-06 4:35 ` [PATCH 4/4] gcc-4.7: Backport libgcc fixes to appease the new build sequence Khem Raj 2012-09-09 6:02 ` [PATCH 0/4] GCC fixes and updates Khem Raj 2012-09-12 17:43 ` Saul Wold
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.