All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH 0/5] Moving to a two stage gcc build
@ 2014-09-14  9:49 Thomas Petazzoni
  2014-09-14  9:49 ` [Buildroot] [PATCH 1/5] toolchain: switch " Thomas Petazzoni
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2014-09-14  9:49 UTC (permalink / raw)
  To: buildroot

Hello,

Here is a new iteration of the patch series moving from a three stage
gcc build to a two stage gcc build, which obviously speeds up quite a
bit the toolchain build process. This time around, I've done a *lot*
more testing, and I've fixed the Stack Smashing Protection issue that
lead to reverting the previous solution (back in October 2013).

You can see the results at:

  https://docs.google.com/spreadsheets/d/1Qj3t6HJzuVxsqLfXZp3HiFMGrangmRl510BqR_VIOeM/edit?usp=sharing

I've done build testing on all architectures that we support (except
I've done tested all little endian / big endian variations of the
different architectures), and I've done runtime testing on all the
architectures for which we have Qemu support. This testing has been
done for the three supported C libraries: glibc, uclibc and musl (I
haven't done eglibc testing, since it's going away, and should be
identical to glibc).

This testing was done with a variety of compiler versions, C library
versions (for glibc), and toolchain configuration. Of course, I
haven't tested *all* possible combinations, but quite a few.

The results show that this patch series does not introduce
regressions: the configuration that do not build or do not run on
target also fail in the same way on the master branch:

 - ARC build fails in Busybox, like in master (but the toolchain
   builds fine)

 - mips64el/uclibc build and mipsel/uclibc build fail to run, like in
   master.

 - powerpc/musl fails to build, since it doesn't have SPE support,
   like in master (patches from Gustavo pending).

 - sh4 toolchain is broken, like in master.

I'd like to call people using the internal toolchain backend to please
test this patch series (both build time and run time), and report any
issue or send their Tested-by. We're still relatively early in the
development cycle, it's the good moment to get such changes merged.

Thanks!

Thomas

Thomas Petazzoni (5):
  toolchain: switch to a two stage gcc build
  gcc/gcc-intermediate: remove package
  musl: two-stage gcc simplifications
  glibc: two-stage gcc simplifications
  uclibc: two-stage gcc simplifications

 package/gcc/gcc-initial/gcc-initial.mk           | 20 +++++++++-
 package/gcc/gcc-intermediate/gcc-intermediate.mk | 49 ------------------------
 package/gcc/gcc.mk                               |  3 +-
 package/glibc/glibc.mk                           | 15 +-------
 package/musl/musl.mk                             | 27 +------------
 package/uclibc/uclibc.mk                         | 25 +-----------
 6 files changed, 24 insertions(+), 115 deletions(-)
 delete mode 100644 package/gcc/gcc-intermediate/gcc-intermediate.mk

-- 
2.0.0

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH 1/5] toolchain: switch to a two stage gcc build
  2014-09-14  9:49 [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Thomas Petazzoni
@ 2014-09-14  9:49 ` Thomas Petazzoni
  2014-09-14  9:50 ` [Buildroot] [PATCH 2/5] gcc/gcc-intermediate: remove package Thomas Petazzoni
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2014-09-14  9:49 UTC (permalink / raw)
  To: buildroot

Currently, the internal toolchain backend does a three stage gcc
build, with the following sequence of builds:

 - build gcc-initial
 - configure libc, install headers and start files
 - build gcc-intermediate
 - build libc
 - build gcc-final

However, it turns out that this is not necessary, and only a two stage
gcc build is needed. At some point, it was believed that a three stage
gcc build was needed for NPTL based toolchains with old gcc versions,
but even a gcc 4.4 build with a NPTL toolchain works fine.

So, this commit switches the internal toolchain backend to use a two
stage gcc build: just gcc-initial and gcc-final. It does so by:

 * Removing the custom dependency of all C libraries build step to
   host-gcc-intermediate. Now the C library packages simply have to
   depend on host-gcc-initial as a normal dependency (which they
   already do), and that's it.

 * Build and install both gcc *and* libgcc in
   host-gcc-initial. Previously, only gcc was built and installed in
   host-gcc-initial. libgcc was only done in host-gcc-intermediate,
   but now we need libgcc to build the C library.

 * Pass appropriate environment variables to get SSP (Stack Smashing
   Protection) to work properly:

    - Tell the compiler that the libc will provide the SSP support, by
      passing gcc_cv_libc_provides_ssp=yes. In Buildroot, we have
      chosen to use the SSP support from the C library instead of the
      SSP support from the compiler (this is not changed by this patch
      series, it was already the case).

    - Tell glibc to *not* build its own programs with SSP support. The
      issue is that if glibc detects that the compiler supports
      -fstack-protector, then glibc uses it to build a few things with
      SSP. However, at this point, the support is not complete (we
      only have host-gcc-initial, and the C library is not completely
      built). So, we pass libc_cv_ssp=no to tell the C library to not
      use SSP support itself. Note that this is not a big lose: only a
      few parts of the C library were built with -fstack-protector,
      not the entire library.

 * A special change is needed for ARC, because its libgcc depends on
   the C library, which breaks building libgcc in
   host-gcc-initial. This looks like a bug in the ARC compiler, as it
   does not obey the inhibit_libc variable which tells the compiler
   build process to *not* enable things that depend on the C
   library. So for now, in host-gcc-initial, we simply disable the
   build of libgmon.a for ARC. It's going to be built as part of
   host-gcc-final, so the final compiler will have gmon support.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/gcc/gcc-initial/gcc-initial.mk | 20 ++++++++++++++++++--
 package/glibc/glibc.mk                 |  4 +---
 package/musl/musl.mk                   |  3 ---
 package/uclibc/uclibc.mk               |  3 ---
 4 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/package/gcc/gcc-initial/gcc-initial.mk b/package/gcc/gcc-initial/gcc-initial.mk
index bc5ad26..4470477 100644
--- a/package/gcc/gcc-initial/gcc-initial.mk
+++ b/package/gcc/gcc-initial/gcc-initial.mk
@@ -24,11 +24,24 @@ HOST_GCC_INITIAL_SUBDIR = build
 
 HOST_GCC_INITIAL_PRE_CONFIGURE_HOOKS += HOST_GCC_CONFIGURE_SYMLINK
 
+# gcc on ARC has a bug: in its libgcc, even when no C library is
+# available (--with-newlib is passed, and therefore inhibit_libc is
+# defined), it tries to use the C library for the libgmon
+# library. Since it's not needed in gcc-initial, we disabled it here.
+ifeq ($(BR2_GCC_VERSION_4_8_ARC),y)
+define HOST_GCC_INITIAL_DISABLE_LIBGMON
+	$(SED) 's/crtbeginS.o libgmon.a crtg.o/crtbeginS.o crtg.o/' \
+		$(@D)/libgcc/config.host
+endef
+HOST_GCC_INITIAL_POST_PATCH_HOOKS += HOST_GCC_INITIAL_DISABLE_LIBGMON
+endif
+
 HOST_GCC_INITIAL_CONF_OPT = \
 	$(HOST_GCC_COMMON_CONF_OPT) \
 	--enable-languages=c \
 	--disable-shared \
 	--without-headers \
+	--disable-threads \
 	--with-newlib \
 	--disable-largefile \
 	--disable-nls \
@@ -37,7 +50,10 @@ HOST_GCC_INITIAL_CONF_OPT = \
 HOST_GCC_INITIAL_CONF_ENV = \
 	$(HOST_GCC_COMMON_CONF_ENV)
 
-HOST_GCC_INITIAL_MAKE_OPT = all-gcc
-HOST_GCC_INITIAL_INSTALL_OPT = install-gcc
+# We need to tell gcc that the C library will be providing the ssp
+# support, as it can't guess it since the C library hasn't been built
+# yet (we're gcc-initial).
+HOST_GCC_INITIAL_MAKE_OPT = $(if $(BR2_TOOLCHAIN_HAS_SSP),gcc_cv_libc_provides_ssp=yes) all-gcc all-target-libgcc
+HOST_GCC_INITIAL_INSTALL_OPT = install-gcc install-target-libgcc
 
 $(eval $(host-autotools-package))
diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
index 4cbca88..0f63445 100644
--- a/package/glibc/glibc.mk
+++ b/package/glibc/glibc.mk
@@ -79,6 +79,7 @@ define GLIBC_CONFIGURE_CMDS
 		$(SHELL) $(@D)/$(GLIBC_SRC_SUBDIR)/configure \
 		ac_cv_path_BASH_SHELL=/bin/bash \
 		libc_cv_forced_unwind=yes \
+		libc_cv_ssp=no \
 		--target=$(GNU_TARGET_NAME) \
 		--host=$(GNU_TARGET_NAME) \
 		--build=$(GNU_HOST_NAME) \
@@ -127,6 +128,3 @@ define GLIBC_INSTALL_TARGET_CMDS
 endef
 
 $(eval $(autotools-package))
-
-# Before (e)glibc is built, we must have the second stage cross-compiler
-$(GLIBC_TARGET_BUILD): | host-gcc-intermediate
diff --git a/package/musl/musl.mk b/package/musl/musl.mk
index 63607f9..2eccb3d 100644
--- a/package/musl/musl.mk
+++ b/package/musl/musl.mk
@@ -68,6 +68,3 @@ define MUSL_INSTALL_TARGET_CMDS
 endef
 
 $(eval $(generic-package))
-
-# Before musl is built, we must have the second stage cross-compiler
-$(MUSL_TARGET_BUILD): | host-gcc-intermediate
diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
index c68dc56..31ff47b 100644
--- a/package/uclibc/uclibc.mk
+++ b/package/uclibc/uclibc.mk
@@ -534,6 +534,3 @@ define UCLIBC_INSTALL_STAGING_CMDS
 endef
 
 $(eval $(kconfig-package))
-
-# Before uClibc is built, we must have the second stage cross-compiler
-$(UCLIBC_TARGET_BUILD): | host-gcc-intermediate
-- 
2.0.0

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH 2/5] gcc/gcc-intermediate: remove package
  2014-09-14  9:49 [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Thomas Petazzoni
  2014-09-14  9:49 ` [Buildroot] [PATCH 1/5] toolchain: switch " Thomas Petazzoni
@ 2014-09-14  9:50 ` Thomas Petazzoni
  2014-09-14  9:50 ` [Buildroot] [PATCH 3/5] musl: two-stage gcc simplifications Thomas Petazzoni
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2014-09-14  9:50 UTC (permalink / raw)
  To: buildroot

Now that we have switched to a two steps gcc build process that uses
only gcc-initial and gcc-final, we can get rid of the gcc-intermediate
package.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/gcc/gcc-intermediate/gcc-intermediate.mk | 49 ------------------------
 package/gcc/gcc.mk                               |  3 +-
 2 files changed, 1 insertion(+), 51 deletions(-)
 delete mode 100644 package/gcc/gcc-intermediate/gcc-intermediate.mk

diff --git a/package/gcc/gcc-intermediate/gcc-intermediate.mk b/package/gcc/gcc-intermediate/gcc-intermediate.mk
deleted file mode 100644
index db84d18..0000000
--- a/package/gcc/gcc-intermediate/gcc-intermediate.mk
+++ /dev/null
@@ -1,49 +0,0 @@
-################################################################################
-#
-# gcc-intermediate
-#
-################################################################################
-
-GCC_INTERMEDIATE_VERSION = $(GCC_VERSION)
-GCC_INTERMEDIATE_SITE    = $(GCC_SITE)
-GCC_INTERMEDIATE_SOURCE  = $(GCC_SOURCE)
-
-HOST_GCC_INTERMEDIATE_DEPENDENCIES = \
-	$(HOST_GCC_COMMON_DEPENDENCIES) \
-	$(BR_LIBC)-configure
-
-HOST_GCC_INTERMEDIATE_EXTRACT_CMDS = $(HOST_GCC_EXTRACT_CMDS)
-
-ifneq ($(call qstrip, $(BR2_XTENSA_CORE_NAME)),)
-HOST_GCC_INTERMEDIATE_POST_EXTRACT_HOOKS += HOST_GCC_XTENSA_OVERLAY_EXTRACT
-endif
-
-HOST_GCC_INTERMEDIATE_POST_PATCH_HOOKS += HOST_GCC_APPLY_PATCHES
-
-# gcc doesn't support in-tree build, so we create a 'build'
-# subdirectory in the gcc sources, and build from there.
-HOST_GCC_INTERMEDIATE_SUBDIR = build
-
-HOST_GCC_INTERMEDIATE_PRE_CONFIGURE_HOOKS += HOST_GCC_CONFIGURE_SYMLINK
-
-HOST_GCC_INTERMEDIATE_CONF_OPT = \
-	$(HOST_GCC_COMMON_CONF_OPT) \
-	--enable-languages=c \
-	--disable-largefile \
-	--disable-nls \
-	$(call qstrip,$(BR2_EXTRA_GCC_CONFIG_OPTIONS))
-
-HOST_GCC_INTERMEDIATE_CONF_ENV = \
-	$(HOST_GCC_COMMON_CONF_ENV)
-
-HOST_GCC_INTERMEDIATE_MAKE_OPT = all-gcc
-ifeq ($(BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE),y)
-HOST_GCC_INTERMEDIATE_MAKE_OPT += all-target-libgcc
-endif
-
-HOST_GCC_INTERMEDIATE_INSTALL_OPT = install-gcc
-ifeq ($(BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE),y)
-HOST_GCC_INTERMEDIATE_INSTALL_OPT += install-target-libgcc
-endif
-
-$(eval $(host-autotools-package))
diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index b344a14..7da4ee2 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -1,7 +1,6 @@
 ################################################################################
 #
-# Common variables for the gcc-initial, gcc-intermediate and gcc-final
-# packages.
+# Common variables for the gcc-initial and gcc-final packages.
 #
 ################################################################################
 
-- 
2.0.0

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH 3/5] musl: two-stage gcc simplifications
  2014-09-14  9:49 [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Thomas Petazzoni
  2014-09-14  9:49 ` [Buildroot] [PATCH 1/5] toolchain: switch " Thomas Petazzoni
  2014-09-14  9:50 ` [Buildroot] [PATCH 2/5] gcc/gcc-intermediate: remove package Thomas Petazzoni
@ 2014-09-14  9:50 ` Thomas Petazzoni
  2014-09-14  9:50 ` [Buildroot] [PATCH 4/5] glibc: " Thomas Petazzoni
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2014-09-14  9:50 UTC (permalink / raw)
  To: buildroot

After switching to a two stage gcc solution, there is no longer a need
to do weird things in the musl build, with certain things being done
twice (MUSL_CONFIGURE_CALL). Now the MUSL_CONFIGURE_CMDS variable only
does the configuration, and the MUSL_BUILD_CMDS only does the build,
as it should be.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/musl/musl.mk | 24 ++----------------------
 1 file changed, 2 insertions(+), 22 deletions(-)

diff --git a/package/musl/musl.mk b/package/musl/musl.mk
index 2eccb3d..2b366cf 100644
--- a/package/musl/musl.mk
+++ b/package/musl/musl.mk
@@ -18,15 +18,7 @@ MUSL_ADD_TOOLCHAIN_DEPENDENCY = NO
 
 MUSL_INSTALL_STAGING = YES
 
-# We need to run the musl configure script prior to building the
-# gcc-intermediate, so that we can call the install-headers step and
-# get the crt<X>.o built. However, we need to call it again after
-# gcc-intermediate has been built, otherwise the configure script
-# doesn't realize that libgcc has been built, and doesn't link the C
-# library properly with libgcc, which causes build failure down the
-# road. We will have the opportunity to simplify this once we switch
-# to a 2-steps gcc build.
-define MUSL_CONFIGURE_CALL
+define MUSL_CONFIGURE_CMDS
 	(cd $(@D); \
 		$(TARGET_CONFIGURE_OPTS) \
 		CFLAGS="$(filter-out -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64,$(TARGET_CFLAGS)) $(MUSL_EXTRA_CFLAGS)" \
@@ -38,25 +30,13 @@ define MUSL_CONFIGURE_CALL
 			--disable-gcc-wrapper)
 endef
 
-define MUSL_CONFIGURE_CMDS
-	$(MUSL_CONFIGURE_CALL)
-	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \
-		DESTDIR=$(STAGING_DIR) install-headers
-	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \
-		crt/crt1.o crt/crti.o crt/crtn.o
-	cp $(@D)/crt/crt*.o $(STAGING_DIR)/usr/lib
-	$(TARGET_CROSS)gcc -nostdlib \
-		-nostartfiles -shared -x c /dev/null -o $(STAGING_DIR)/usr/lib/libc.so
-endef
-
 define MUSL_BUILD_CMDS
-	$(MUSL_CONFIGURE_CALL)
 	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)
 endef
 
 define MUSL_INSTALL_STAGING_CMDS
 	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \
-		DESTDIR=$(STAGING_DIR) install-libs install-tools
+		DESTDIR=$(STAGING_DIR) install-libs install-tools install-headers
 endef
 
 # prefix is set to an empty value to get the C library installed in
-- 
2.0.0

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH 4/5] glibc: two-stage gcc simplifications
  2014-09-14  9:49 [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Thomas Petazzoni
                   ` (2 preceding siblings ...)
  2014-09-14  9:50 ` [Buildroot] [PATCH 3/5] musl: two-stage gcc simplifications Thomas Petazzoni
@ 2014-09-14  9:50 ` Thomas Petazzoni
  2014-09-14  9:50 ` [Buildroot] [PATCH 5/5] uclibc: " Thomas Petazzoni
  2014-09-14 21:39 ` [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Peter Korsgaard
  5 siblings, 0 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2014-09-14  9:50 UTC (permalink / raw)
  To: buildroot

After switching to a two stage gcc solution, there is no longer a need
to do weird things in the glibc build. We can greatly simplify
GLIBC_CONFIGURE_CMDS to only do the configuration, and let the
existing GLIBC_BUILD_CMDS do the build.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/glibc/glibc.mk | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
index 0f63445..09b57fa 100644
--- a/package/glibc/glibc.mk
+++ b/package/glibc/glibc.mk
@@ -92,18 +92,7 @@ define GLIBC_CONFIGURE_CMDS
 		--without-gd \
 		--enable-obsolete-rpc \
 		--with-headers=$(STAGING_DIR)/usr/include)
-	# Install headers and start files
-	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/build \
-		install_root=$(STAGING_DIR) \
-		install-bootstrap-headers=yes \
-		install-headers
-	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/build csu/subdir_lib
-	cp $(@D)/build/csu/crt1.o $(STAGING_DIR)/usr/lib/
-	cp $(@D)/build/csu/crti.o $(STAGING_DIR)/usr/lib/
-	cp $(@D)/build/csu/crtn.o $(STAGING_DIR)/usr/lib/
 	$(GLIBC_ADD_MISSING_STUB_H)
-	$(TARGET_CROSS)gcc -nostdlib \
-		-nostartfiles -shared -x c /dev/null -o $(STAGING_DIR)/usr/lib/libc.so
 endef
 
 
-- 
2.0.0

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH 5/5] uclibc: two-stage gcc simplifications
  2014-09-14  9:49 [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Thomas Petazzoni
                   ` (3 preceding siblings ...)
  2014-09-14  9:50 ` [Buildroot] [PATCH 4/5] glibc: " Thomas Petazzoni
@ 2014-09-14  9:50 ` Thomas Petazzoni
  2014-09-14 21:39 ` [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Peter Korsgaard
  5 siblings, 0 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2014-09-14  9:50 UTC (permalink / raw)
  To: buildroot

After switching to a two stage gcc solution, there is no longer a need
to do weird things in the uclibc build. We can greatly simplify
UCLIBC_CONFIGURE_CMDS to only do the configuration, and let the
existing UCLIBC_BUILD_CMDS do the build. Note that we have to build
the headers before starting the C library build, otherwise there is a
build failure (probably a uClibc bug).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/uclibc/uclibc.mk | 22 ++--------------------
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
index 31ff47b..5933973 100644
--- a/package/uclibc/uclibc.mk
+++ b/package/uclibc/uclibc.mk
@@ -433,20 +433,6 @@ define UCLIBC_KCONFIG_FIXUP_CMDS
 	$(UCLIBC_STRIP_CONFIG)
 endef
 
-define UCLIBC_CONFIGURE_CMDS
-	$(MAKE1) -C $(UCLIBC_DIR) \
-		$(UCLIBC_MAKE_FLAGS) \
-		PREFIX=$(STAGING_DIR) \
-		DEVEL_PREFIX=/usr/ \
-		RUNTIME_PREFIX=$(STAGING_DIR) \
-		headers startfiles \
-		install_headers install_startfiles
-	$(TARGET_CROSS)gcc -nostdlib \
-		-nostartfiles -shared -x c /dev/null -o $(STAGING_DIR)/usr/lib/libc.so
-	$(TARGET_CROSS)gcc -nostdlib \
-		-nostartfiles -shared -x c /dev/null -o $(STAGING_DIR)/usr/lib/libm.so
-endef
-
 ifeq ($(BR2_UCLIBC_INSTALL_TEST_SUITE),y)
 define UCLIBC_BUILD_TEST_SUITE
 	$(MAKE1) -C $(@D)/test \
@@ -471,12 +457,8 @@ else
 endif
 
 define UCLIBC_BUILD_CMDS
-	$(UCLIBC_MAKE) -C $(@D) \
-		$(UCLIBC_MAKE_FLAGS) \
-		PREFIX= \
-		DEVEL_PREFIX=/ \
-		RUNTIME_PREFIX=/ \
-		all
+	$(UCLIBC_MAKE) -C $(@D) $(UCLIBC_MAKE_FLAGS) headers
+	$(UCLIBC_MAKE) -C $(@D) $(UCLIBC_MAKE_FLAGS)
 	$(MAKE) -C $(@D)/utils \
 		PREFIX=$(HOST_DIR) \
 		HOSTCC="$(HOSTCC)" hostutils
-- 
2.0.0

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH 0/5] Moving to a two stage gcc build
  2014-09-14  9:49 [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Thomas Petazzoni
                   ` (4 preceding siblings ...)
  2014-09-14  9:50 ` [Buildroot] [PATCH 5/5] uclibc: " Thomas Petazzoni
@ 2014-09-14 21:39 ` Peter Korsgaard
  5 siblings, 0 replies; 7+ messages in thread
From: Peter Korsgaard @ 2014-09-14 21:39 UTC (permalink / raw)
  To: buildroot

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > Here is a new iteration of the patch series moving from a three stage
 > gcc build to a two stage gcc build, which obviously speeds up quite a
 > bit the toolchain build process. This time around, I've done a *lot*
 > more testing, and I've fixed the Stack Smashing Protection issue that
 > lead to reverting the previous solution (back in October 2013).

 > You can see the results at:

 >   https://docs.google.com/spreadsheets/d/1Qj3t6HJzuVxsqLfXZp3HiFMGrangmRl510BqR_VIOeM/edit?usp=sharing

Nice!

Committed series, thanks.

 > I'd like to call people using the internal toolchain backend to please
 > test this patch series (both build time and run time), and report any
 > issue or send their Tested-by. We're still relatively early in the
 > development cycle, it's the good moment to get such changes merged.

Yes please!

-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-09-14 21:39 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-14  9:49 [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Thomas Petazzoni
2014-09-14  9:49 ` [Buildroot] [PATCH 1/5] toolchain: switch " Thomas Petazzoni
2014-09-14  9:50 ` [Buildroot] [PATCH 2/5] gcc/gcc-intermediate: remove package Thomas Petazzoni
2014-09-14  9:50 ` [Buildroot] [PATCH 3/5] musl: two-stage gcc simplifications Thomas Petazzoni
2014-09-14  9:50 ` [Buildroot] [PATCH 4/5] glibc: " Thomas Petazzoni
2014-09-14  9:50 ` [Buildroot] [PATCH 5/5] uclibc: " Thomas Petazzoni
2014-09-14 21:39 ` [Buildroot] [PATCH 0/5] Moving to a two stage gcc build Peter Korsgaard

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.