All of lore.kernel.org
 help / color / mirror / Atom feed
* [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
* [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
* [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 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
* 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 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 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 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
* 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
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.