GCC fixes and updates

arm patch is a forward port from OE/classic
ppc patch should help in building images with Os

Signed-off-by Khem Raj <[email protected]>

---

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

meta/recipes-devtools/gcc/gcc-4.7.inc +0 -0

index affbd54..b455b28 100644
@@ -1,6 +1,6 @@

require gcc-common.inc

meta/recipes-devtools/gcc/gcc-4.7.inc +1 -1

-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

meta/recipes-devtools/gcc/gcc-4.7.inc +2 -0

@@ -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}"

meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch new file +29 -0

new file mode 100644
index 0000000..6cd645a
@@ -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)
+ 

meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch new file +21 -0

new file mode 100644
index 0000000..88684d3
@@ -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
+

Signature · 7 lines

1.7.9.5


_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/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 <[email protected]>

---
meta/recipes-devtools/gcc/gcc-4.7.inc | 8 ++++----

1 file changed, 4 insertions(+), 4 deletions(-)

meta/recipes-devtools/gcc/gcc-4.7.inc +0 -0

index 84c230c..affbd54 100644

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

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 <[email protected]>

---
  meta/recipes-devtools/gcc/gcc-4.7.inc |    8 ++++----
  1 file changed, 4 insertions(+), 4 deletions(-)

meta/recipes-devtools/gcc/gcc-4.7.inc +4 -4

index 84c230c..affbd54 100644
@@ -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

Quoted 6 lines · Khem Raj

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 <[email protected]>

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...

Quoted 9 lines · Gary Thomas

Quoted 6 lines · Khem Raj

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 <[email protected]>

What about this patch? Carrying around a 1.7GB (Sorry, Khem, that's

Quoted 1 line

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

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/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

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.

Quoted 3 lines · Khem Raj

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.

Quoted 6 lines · Björn Stenberg

Quoted 3 lines · Khem Raj

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.

Quoted 6 lines · Otavio Salvador

Quoted 5 lines · Björn Stenberg

Quoted 3 lines · Khem Raj

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.

Quoted 4 lines

Quoted 1 line

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.

Quoted 8 lines · Chris Larson

Quoted 6 lines · Otavio Salvador

Quoted 5 lines · Björn Stenberg

Quoted 3 lines · Khem Raj

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.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 8 lines · Chris Larson

Quoted 6 lines · Otavio Salvador

Quoted 5 lines · Björn Stenberg

Quoted 3 lines · Khem Raj

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.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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?

Quoted 28 lines · Richard Purdie

Quoted 8 lines · Chris Larson

Quoted 6 lines · Otavio Salvador

Quoted 5 lines · Björn Stenberg

Quoted 3 lines · Khem Raj

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.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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.

Quoted 3 lines

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?

Quoted 34 lines · Otavio Salvador

Quoted 31 lines · Richard Purdie

Quoted 8 lines · Chris Larson

Quoted 6 lines · Otavio Salvador

Quoted 5 lines · Björn Stenberg

Quoted 3 lines · Khem Raj

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.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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?

Quoted 1 line

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.

Quoted 35 lines · Richard Purdie

Quoted 34 lines · Otavio Salvador

Quoted 31 lines · Richard Purdie

Quoted 8 lines · Chris Larson

Quoted 6 lines · Otavio Salvador

Quoted 5 lines · Björn Stenberg

Quoted 3 lines · Khem Raj

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.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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?

Quoted 5 lines

Quoted 1 line

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: [email protected] http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br

_______________________________________________
bitbake-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel

Quoted 8 lines · Chris Larson

Quoted 6 lines · Otavio Salvador

Quoted 5 lines · Björn Stenberg

Quoted 3 lines · Khem Raj

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.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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

_______________________________________________
bitbake-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel