kumquat-buildroot/package/gcc/gcc.mk

356 lines
12 KiB
Makefile
Raw Normal View History

################################################################################
#
# Common variables for the gcc-initial and gcc-final packages.
#
################################################################################
#
# Version, site and source
#
GCC_VERSION = $(call qstrip,$(BR2_GCC_VERSION))
ifeq ($(BR2_arc),y)
GCC_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,gcc,$(GCC_VERSION))
GCC_SOURCE = gcc-$(GCC_VERSION).tar.gz
else
GCC_SITE = $(BR2_GNU_MIRROR:/=)/gcc/gcc-$(GCC_VERSION)
endif
GCC_SOURCE ?= gcc-$(GCC_VERSION).tar.bz2
#
# Xtensa special hook
#
ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Danomi Manchego <danomimanchego123@gmail.com> Cc: Károly Kasza <kaszak@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 17:25:00 +02:00
HOST_GCC_XTENSA_OVERLAY_TAR = $(BR2_XTENSA_OVERLAY_DIR)/xtensa_$(call qstrip,$(BR2_XTENSA_CORE_NAME)).tar
define HOST_GCC_XTENSA_OVERLAY_EXTRACT
ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Danomi Manchego <danomimanchego123@gmail.com> Cc: Károly Kasza <kaszak@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 17:25:00 +02:00
tar xf $(HOST_GCC_XTENSA_OVERLAY_TAR) -C $(@D) --strip-components=1 gcc
endef
#
# Apply patches
#
ifeq ($(ARCH),powerpc)
ifneq ($(BR2_SOFT_FLOAT),)
define HOST_GCC_APPLY_POWERPC_PATCH
$(APPLY_PATCHES) $(@D) package/gcc/$(GCC_VERSION) 1000-powerpc-link-with-math-lib.patch.conditional
endef
endif
endif
# gcc is a special package, not named gcc, but gcc-initial and
# gcc-final, but patches are nonetheless stored in package/gcc in the
# tree, and potentially in BR2_GLOBAL_PATCH_DIR directories as well.
define HOST_GCC_APPLY_PATCHES
for patchdir in \
package/gcc/$(GCC_VERSION) \
$(addsuffix /gcc/$(GCC_VERSION),$(call qstrip,$(BR2_GLOBAL_PATCH_DIR))) \
$(addsuffix /gcc,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR))) ; do \
if test -d $${patchdir}; then \
$(APPLY_PATCHES) $(@D) $${patchdir} \*.patch || exit 1; \
fi; \
done
$(HOST_GCC_APPLY_POWERPC_PATCH)
endef
HOST_GCC_EXCLUDES = \
libjava/* libgo/* \
gcc/testsuite/* libstdc++-v3/testsuite/*
define HOST_GCC_FAKE_TESTSUITE
mkdir -p $(@D)/libstdc++-v3/testsuite/
echo "all:" > $(@D)/libstdc++-v3/testsuite/Makefile.in
echo "install:" >> $(@D)/libstdc++-v3/testsuite/Makefile.in
endef
#
# Create 'build' directory and configure symlink
#
define HOST_GCC_CONFIGURE_SYMLINK
mkdir -p $(@D)/build
ln -sf ../configure $(@D)/build/configure
endef
#
# Common configuration options
#
HOST_GCC_COMMON_DEPENDENCIES = \
host-binutils \
host-gmp \
host-mpc \
host-mpfr \
$(if $(BR2_BINFMT_FLAT),host-elf2flt)
HOST_GCC_COMMON_CONF_OPTS = \
--target=$(GNU_TARGET_NAME) \
--with-sysroot=$(STAGING_DIR) \
--disable-__cxa_atexit \
--with-gnu-ld \
--disable-libssp \
--disable-multilib \
--with-gmp=$(HOST_DIR)/usr \
--with-mpc=$(HOST_DIR)/usr \
--with-mpfr=$(HOST_DIR)/usr \
--with-pkgversion="Buildroot $(BR2_VERSION_FULL)" \
--with-bugurl="http://bugs.buildroot.net/"
# Don't build documentation. It takes up extra space / build time,
# and sometimes needs specific makeinfo versions to work
HOST_GCC_COMMON_CONF_ENV = \
MAKEINFO=missing
GCC_COMMON_TARGET_CFLAGS = $(TARGET_CFLAGS)
GCC_COMMON_TARGET_CXXFLAGS = $(TARGET_CXXFLAGS)
# Propagate options used for target software building to GCC target libs
HOST_GCC_COMMON_CONF_ENV += CFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CFLAGS)"
HOST_GCC_COMMON_CONF_ENV += CXXFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CXXFLAGS)"
# libitm needs sparc V9+
ifeq ($(BR2_sparc_v8)$(BR2_sparc_leon3),y)
HOST_GCC_COMMON_CONF_OPTS += --disable-libitm
endif
# quadmath support requires wchar
ifeq ($(BR2_USE_WCHAR)$(BR2_TOOLCHAIN_HAS_LIBQUADMATH),yy)
HOST_GCC_COMMON_CONF_OPTS += --enable-libquadmath
else
HOST_GCC_COMMON_CONF_OPTS += --disable-libquadmath
endif
# libsanitizer requires wordexp, not in default uClibc config. Also
# doesn't build properly with musl.
ifeq ($(BR2_TOOLCHAIN_BUILDROOT_UCLIBC)$(BR2_TOOLCHAIN_BUILDROOT_MUSL),y)
HOST_GCC_COMMON_CONF_OPTS += --disable-libsanitizer
endif
# libsanitizer is broken for SPARC
# https://bugs.busybox.net/show_bug.cgi?id=7951
ifeq ($(BR2_sparc)$(BR2_sparc64),y)
HOST_GCC_COMMON_CONF_OPTS += --disable-libsanitizer
endif
gcc: remove BR2_GCC_ENABLE_TLS option The current BR2_GCC_ENABLE_TLS can cause users to make incorrect choices, and is not very useful. This options allows to decide whether we pass --enable-tls or --disable-tls to gcc, to enable or disable support for Thread Local Storage. Its behavior is: - The option is default to "y" but only exists if we're using uClibc/NPTL or glibc. - When we're using uClibc, the option can be disabled. So, in practice, this means that currently: - TLS support is always on for glibc - TLS support is on by default for uClibc/NPTL, but can be disabled in the configuration. This is in fact bad and causes the build failure reported in bug #7424 (this bug is still reproducible on master) - TLS support is always disabled for uClibc/no-thread and uClibc/linuxthreads. - TLS support is always disabled for musl. This does not cause any build failure, but musl can use TLS support, and therefore be more efficient. According to http://www.openwall.com/lists/musl/2012/10/04/1, "Note that if you've been building gcc with --disable-tls, __thread was already working but gets emulated (very poorly; it's slow and will abort() if it runs out of memory) through libgcc.". So, this commit completely removes the BR2_GCC_ENABLE_TLS and instead makes the right choice inside gcc.mk directly: - TLS support enabled for glibc, musl and uClibc/NPTL - TLS support in other cases, i.e uClibc/no-thread and uClibc/linuxthreads. We have intentionally *not* added the option to Config.in.legacy. Indeed, the new behavior is *exactly* the same as the older behavior, with the exception of: - People can no longer disable TLS support in uClibc/NPTL, which was anyway causing a build failure and therefore was not used. - TLS support is now enabled on musl, but people using musl already had BR2_GCC_ENABLE_TLS not set, so they wouldn't get the legacy warning. Fixes bug #7424. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2016-08-30 23:33:28 +02:00
# TLS support is not needed on uClibc/no-thread and
# uClibc/linux-threads, otherwise, for all other situations (glibc,
# musl and uClibc/NPTL), we need it.
ifeq ($(BR2_TOOLCHAIN_BUILDROOT_UCLIBC)$(BR2_PTHREADS)$(BR2_PTHREADS_NONE),yy)
HOST_GCC_COMMON_CONF_OPTS += --disable-tls
gcc: remove BR2_GCC_ENABLE_TLS option The current BR2_GCC_ENABLE_TLS can cause users to make incorrect choices, and is not very useful. This options allows to decide whether we pass --enable-tls or --disable-tls to gcc, to enable or disable support for Thread Local Storage. Its behavior is: - The option is default to "y" but only exists if we're using uClibc/NPTL or glibc. - When we're using uClibc, the option can be disabled. So, in practice, this means that currently: - TLS support is always on for glibc - TLS support is on by default for uClibc/NPTL, but can be disabled in the configuration. This is in fact bad and causes the build failure reported in bug #7424 (this bug is still reproducible on master) - TLS support is always disabled for uClibc/no-thread and uClibc/linuxthreads. - TLS support is always disabled for musl. This does not cause any build failure, but musl can use TLS support, and therefore be more efficient. According to http://www.openwall.com/lists/musl/2012/10/04/1, "Note that if you've been building gcc with --disable-tls, __thread was already working but gets emulated (very poorly; it's slow and will abort() if it runs out of memory) through libgcc.". So, this commit completely removes the BR2_GCC_ENABLE_TLS and instead makes the right choice inside gcc.mk directly: - TLS support enabled for glibc, musl and uClibc/NPTL - TLS support in other cases, i.e uClibc/no-thread and uClibc/linuxthreads. We have intentionally *not* added the option to Config.in.legacy. Indeed, the new behavior is *exactly* the same as the older behavior, with the exception of: - People can no longer disable TLS support in uClibc/NPTL, which was anyway causing a build failure and therefore was not used. - TLS support is now enabled on musl, but people using musl already had BR2_GCC_ENABLE_TLS not set, so they wouldn't get the legacy warning. Fixes bug #7424. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2016-08-30 23:33:28 +02:00
else
HOST_GCC_COMMON_CONF_OPTS += --enable-tls
endif
toolchain: add link-time-optimization support Add a new option BR2_GCC_ENABLE_LTO that builds gcc and binutils with LTO support. Individual packages still have to enable LTO explicitly by passing '-flto' to GCC, which passes it on to the linker. This option does not add that flag globally. Some packages detect if the compiler supports LTO and enable the flag if it does. To support LTO, ar and ranlib must be called with an argument which triggers the usage of the LTO plugin. Since GCC doesn't call these tools itself, it instead provides wrappers for ar and ranlib that pass the LTO arguments. This way existing Makefiles don't need to be changed for LTO support. However, these wrappers are called <tuple>-gcc-ar which matches the pattern to link to the buildroot wrapper in the external toolchain logic. So the external toolchain logic is updated to provide the correct symlink. [Thomas: - Add a separate BR2_BINUTILS_ENABLE_LTO option to enable LTO support in binutils. This is a blind option, selected by BR2_GCC_ENABLE_LTO. It just avoids having binutils.mk poke directly into gcc Config.in options. - Remove the check on the AVR32 special gcc version, which we don't support anymore. - Adapt the help text of the LTO Config.in option to no longer mention "Since version 4.5", since we only support gcc >= 4.5 in Buildroot anyway. - Fix typo in toolchain-external.mk comment.] Signed-off-by: Peter Kümmel <syntheticpp@gmx.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-06 13:34:06 +01:00
ifeq ($(BR2_GCC_ENABLE_LTO),y)
HOST_GCC_COMMON_CONF_OPTS += --enable-plugins --enable-lto
endif
ifeq ($(BR2_GCC_ENABLE_LIBMUDFLAP),y)
HOST_GCC_COMMON_CONF_OPTS += --enable-libmudflap
else
HOST_GCC_COMMON_CONF_OPTS += --disable-libmudflap
endif
ifeq ($(BR2_PTHREADS_NONE),y)
HOST_GCC_COMMON_CONF_OPTS += \
--disable-threads \
--disable-libitm \
--disable-libatomic
else
HOST_GCC_COMMON_CONF_OPTS += --enable-threads
endif
ifeq ($(BR2_GCC_ENABLE_GRAPHITE),y)
HOST_GCC_COMMON_DEPENDENCIES += host-isl
HOST_GCC_COMMON_CONF_OPTS += --with-isl=$(HOST_DIR)/usr
# gcc 5 doesn't need cloog any more, see
# https://gcc.gnu.org/gcc-5/changes.html
ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_5),)
HOST_GCC_COMMON_DEPENDENCIES += host-cloog
HOST_GCC_COMMON_CONF_OPTS += --with-cloog=$(HOST_DIR)/usr
endif
else
HOST_GCC_COMMON_CONF_OPTS += --without-isl --without-cloog
endif
ifeq ($(BR2_arc),y)
HOST_GCC_COMMON_DEPENDENCIES += host-flex host-bison
endif
ifeq ($(BR2_SOFT_FLOAT),y)
# only mips*-*-*, arm*-*-* and sparc*-*-* accept --with-float
# powerpc seems to be needing it as well
ifeq ($(BR2_arm)$(BR2_armeb)$(BR2_mips)$(BR2_mipsel)$(BR2_mips64)$(BR2_mips64el)$(BR2_powerpc)$(BR2_sparc),y)
HOST_GCC_COMMON_CONF_OPTS += --with-float=soft
endif
endif
ifeq ($(BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE),y)
HOST_GCC_COMMON_CONF_OPTS += --disable-decimal-float
endif
# Determine arch/tune/abi/cpu options
ifeq ($(BR2_GCC_ARCH_HAS_CONFIGURABLE_DEFAULTS),y)
ifneq ($(call qstrip,$(BR2_GCC_TARGET_ARCH)),)
HOST_GCC_COMMON_CONF_OPTS += --with-arch=$(BR2_GCC_TARGET_ARCH)
endif
ifneq ($(call qstrip,$(BR2_GCC_TARGET_ABI)),)
HOST_GCC_COMMON_CONF_OPTS += --with-abi=$(BR2_GCC_TARGET_ABI)
endif
ifneq ($(call qstrip,$(BR2_GCC_TARGET_CPU)),)
ifneq ($(call qstrip,$(BR2_GCC_TARGET_CPU_REVISION)),)
HOST_GCC_COMMON_CONF_OPTS += --with-cpu=$(call qstrip,$(BR2_GCC_TARGET_CPU)-$(BR2_GCC_TARGET_CPU_REVISION))
else
HOST_GCC_COMMON_CONF_OPTS += --with-cpu=$(call qstrip,$(BR2_GCC_TARGET_CPU))
endif
endif
GCC_TARGET_FPU = $(call qstrip,$(BR2_GCC_TARGET_FPU))
ifneq ($(GCC_TARGET_FPU),)
HOST_GCC_COMMON_CONF_OPTS += --with-fpu=$(GCC_TARGET_FPU)
endif
GCC_TARGET_FLOAT_ABI = $(call qstrip,$(BR2_GCC_TARGET_FLOAT_ABI))
ifneq ($(GCC_TARGET_FLOAT_ABI),)
HOST_GCC_COMMON_CONF_OPTS += --with-float=$(GCC_TARGET_FLOAT_ABI)
endif
GCC_TARGET_MODE = $(call qstrip,$(BR2_GCC_TARGET_MODE))
ifneq ($(GCC_TARGET_MODE),)
HOST_GCC_COMMON_CONF_OPTS += --with-mode=$(GCC_TARGET_MODE)
endif
endif # BR2_GCC_ARCH_HAS_CONFIGURABLE_DEFAULTS
# Enable proper double/long double for SPE ABI
ifeq ($(BR2_powerpc_SPE),y)
HOST_GCC_COMMON_CONF_OPTS += \
--enable-e500_double \
--with-long-double-128
endif
# PowerPC64 big endian by default uses the elfv1 ABI, and PowerPC 64
# little endian by default uses the elfv2 ABI. However, musl has
# decided to use the elfv2 ABI for both, so we force the elfv2 ABI for
# Power64 big endian when the selected C library is musl.
ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_powerpc64),yy)
HOST_GCC_COMMON_CONF_OPTS += \
--with-abi=elfv2 \
--without-long-double-128
endif
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".br_real"'
ifeq ($(BR2_GCC_ARCH_HAS_CONFIGURABLE_DEFAULTS),)
ifeq ($(call qstrip,$(BR2_GCC_TARGET_CPU_REVISION)),)
HOST_GCC_COMMON_WRAPPER_TARGET_CPU := $(call qstrip,$(BR2_GCC_TARGET_CPU))
else
HOST_GCC_COMMON_WRAPPER_TARGET_CPU := $(call qstrip,$(BR2_GCC_TARGET_CPU)-$(BR2_GCC_TARGET_CPU_REVISION))
endif
HOST_GCC_COMMON_WRAPPER_TARGET_ARCH := $(call qstrip,$(BR2_GCC_TARGET_ARCH))
HOST_GCC_COMMON_WRAPPER_TARGET_ABI := $(call qstrip,$(BR2_GCC_TARGET_ABI))
HOST_GCC_COMMON_WRAPPER_TARGET_FPU := $(call qstrip,$(BR2_GCC_TARGET_FPU))
HOST_GCC_COMMON_WRAPPER_TARGET_FLOAT_ABI := $(call qstrip,$(BR2_GCC_TARGET_FLOAT_ABI))
HOST_GCC_COMMON_WRAPPER_TARGET_MODE := $(call qstrip,$(BR2_GCC_TARGET_MODE))
ifneq ($(HOST_GCC_COMMON_WRAPPER_TARGET_ARCH),)
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_ARCH='"$(HOST_GCC_COMMON_WRAPPER_TARGET_ARCH)"'
endif
ifneq ($(HOST_GCC_COMMON_WRAPPER_TARGET_CPU),)
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_CPU='"$(HOST_GCC_COMMON_WRAPPER_TARGET_CPU)"'
endif
ifneq ($(HOST_GCC_COMMON_WRAPPER_TARGET_ABI),)
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_ABI='"$(HOST_GCC_COMMON_WRAPPER_TARGET_ABI)"'
endif
ifneq ($(HOST_GCC_COMMON_WRAPPER_TARGET_FPU),)
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_FPU='"$(HOST_GCC_COMMON_WRAPPER_TARGET_FPU)"'
endif
ifneq ($(HOST_GCC_COMMON_WRAPPER_TARGET_FLOATABI_),)
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_FLOAT_ABI='"$(HOST_GCC_COMMON_WRAPPER_TARGET_FLOATABI_)"'
endif
ifneq ($(HOST_GCC_COMMON_WRAPPER_TARGET_MODE),)
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_MODE='"$(HOST_GCC_COMMON_WRAPPER_TARGET_MODE)"'
endif
endif # !BR2_GCC_ARCH_HAS_CONFIGURABLE_DEFAULTS
gcc: use toolchain wrapper We have a toolchain wrapper for external toolchain, but it is also beneficial for internal toolchains, for the following reasons: 1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the compiler even if a package's build system doesn't honor CFLAGS. 2. It allows us to do the unsafe path check (i.e. -I/usr/include) without patching gcc. 3. It makes it simpler to implement building each package with a separate staging directory (per-package staging). 4. It makes it simpler to implement a compiler hash check for ccache. The wrapper is reused from the external toolchain. A third CROSS_PATH_ option is added to the wrapper: in this case, the real executable is in the same directory, with the extension .real. The creation of the simple symlinks is merged with the creation of the wrapper symlinks, otherwise part of the -gcc-ar handling logic would have to be repeated. The complex case-condition could be refactored with the one for the external toolchain, but then it becomes even more complex because they each have special corner cases. For example, the internal toolchain has to handle *.real to avoid creating an extra indirection after host-gcc-{final,initial}-rebuild. Instead of creating the .real files, it would also have been possible to install the internal toolchain in $(HOST_DIR)/opt, similar to what we do for the external toolchain. However, then we would also have to copy things to the sysroot and do more of the magic that the external toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much simpler. Note that gcc-initial has to be wrapped as well, because it is used for building libc and we want to apply the same magic when building libc. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Fabio Porcedda <fabio.porcedda@gmail.com> Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 14:28:42 +02:00
# For gcc-initial, 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.
#
# For gcc-final, the gcc logic to detect whether SSP support is
# available or not in the C library is not working properly for
# uClibc, so let's be explicit as well.
HOST_GCC_COMMON_MAKE_OPTS = \
gcc_cv_libc_provides_ssp=$(if $(BR2_TOOLCHAIN_HAS_SSP),yes,no)
ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Danomi Manchego <danomimanchego123@gmail.com> Cc: Károly Kasza <kaszak@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 17:25:00 +02:00
ifeq ($(BR2_CCACHE),y)
HOST_GCC_COMMON_CCACHE_HASH_FILES += $(DL_DIR)/$(GCC_SOURCE)
# Cfr. PATCH_BASE_DIRS in .stamp_patched, but we catch both versioned
# and unversioned patches unconditionally. Moreover, to facilitate the
# addition of gcc patches in BR2_GLOBAL_PATCH_DIR, we allow them to be
# stored in a sub-directory called 'gcc' even if it's not technically
# the name of the package.
ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Danomi Manchego <danomimanchego123@gmail.com> Cc: Károly Kasza <kaszak@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 17:25:00 +02:00
HOST_GCC_COMMON_CCACHE_HASH_FILES += \
$(sort $(wildcard \
ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Danomi Manchego <danomimanchego123@gmail.com> Cc: Károly Kasza <kaszak@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 17:25:00 +02:00
package/gcc/$(GCC_VERSION)/*.patch \
$(addsuffix /$($(PKG)_RAWNAME)/$(GCC_VERSION)/*.patch,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR))) \
$(addsuffix /$($(PKG)_RAWNAME)/*.patch,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR))) \
$(addsuffix /gcc/$(GCC_VERSION)/*.patch,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR))) \
$(addsuffix /gcc/*.patch,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))))
ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Danomi Manchego <danomimanchego123@gmail.com> Cc: Károly Kasza <kaszak@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 17:25:00 +02:00
ifeq ($(BR2_xtensa),y)
HOST_GCC_COMMON_CCACHE_HASH_FILES += $(HOST_GCC_XTENSA_OVERLAY_TAR)
endif
ifeq ($(ARCH),powerpc)
ifneq ($(BR2_SOFT_FLOAT),)
HOST_GCC_COMMON_CCACHE_HASH_FILES += package/gcc/$(GCC_VERSION)/1000-powerpc-link-with-math-lib.patch.conditional
endif
endif
# _CONF_OPTS contains some references to the absolute path of $(HOST_DIR)
# and a reference to the Buildroot git revision (BR2_VERSION_FULL),
# so substitute those away.
ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Danomi Manchego <danomimanchego123@gmail.com> Cc: Károly Kasza <kaszak@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 17:25:00 +02:00
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_CCACHE_HASH=\"`\
printf '%s\n' $(subst $(HOST_DIR),@HOST_DIR@,\
$(subst --with-pkgversion="Buildroot $(BR2_VERSION_FULL)",,$($(PKG)_CONF_OPTS))) \
ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Danomi Manchego <danomimanchego123@gmail.com> Cc: Károly Kasza <kaszak@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 17:25:00 +02:00
| sha256sum - $(HOST_GCC_COMMON_CCACHE_HASH_FILES) \
| cut -c -64 | tr -d '\n'`\"
endif # BR2_CCACHE
gcc: use toolchain wrapper We have a toolchain wrapper for external toolchain, but it is also beneficial for internal toolchains, for the following reasons: 1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the compiler even if a package's build system doesn't honor CFLAGS. 2. It allows us to do the unsafe path check (i.e. -I/usr/include) without patching gcc. 3. It makes it simpler to implement building each package with a separate staging directory (per-package staging). 4. It makes it simpler to implement a compiler hash check for ccache. The wrapper is reused from the external toolchain. A third CROSS_PATH_ option is added to the wrapper: in this case, the real executable is in the same directory, with the extension .real. The creation of the simple symlinks is merged with the creation of the wrapper symlinks, otherwise part of the -gcc-ar handling logic would have to be repeated. The complex case-condition could be refactored with the one for the external toolchain, but then it becomes even more complex because they each have special corner cases. For example, the internal toolchain has to handle *.real to avoid creating an extra indirection after host-gcc-{final,initial}-rebuild. Instead of creating the .real files, it would also have been possible to install the internal toolchain in $(HOST_DIR)/opt, similar to what we do for the external toolchain. However, then we would also have to copy things to the sysroot and do more of the magic that the external toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much simpler. Note that gcc-initial has to be wrapped as well, because it is used for building libc and we want to apply the same magic when building libc. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Fabio Porcedda <fabio.porcedda@gmail.com> Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 14:28:42 +02:00
# The LTO support in gcc creates wrappers for ar, ranlib and nm which load
# the lto plugin. These wrappers are called *-gcc-ar, *-gcc-ranlib, and
# *-gcc-nm and should be used instead of the real programs when -flto is
# used. However, we should not add the toolchain wrapper for them, and they
# match the *cc-* pattern. Therefore, an additional case is added for *-ar,
# *-ranlib and *-nm.
# According to gfortran manpage, it supports all options supported by gcc, so
# add gfortran to the list of the program called via the Buildroot wrapper.
# Avoid that a .br_real is symlinked a second time.
gcc: use toolchain wrapper We have a toolchain wrapper for external toolchain, but it is also beneficial for internal toolchains, for the following reasons: 1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the compiler even if a package's build system doesn't honor CFLAGS. 2. It allows us to do the unsafe path check (i.e. -I/usr/include) without patching gcc. 3. It makes it simpler to implement building each package with a separate staging directory (per-package staging). 4. It makes it simpler to implement a compiler hash check for ccache. The wrapper is reused from the external toolchain. A third CROSS_PATH_ option is added to the wrapper: in this case, the real executable is in the same directory, with the extension .real. The creation of the simple symlinks is merged with the creation of the wrapper symlinks, otherwise part of the -gcc-ar handling logic would have to be repeated. The complex case-condition could be refactored with the one for the external toolchain, but then it becomes even more complex because they each have special corner cases. For example, the internal toolchain has to handle *.real to avoid creating an extra indirection after host-gcc-{final,initial}-rebuild. Instead of creating the .real files, it would also have been possible to install the internal toolchain in $(HOST_DIR)/opt, similar to what we do for the external toolchain. However, then we would also have to copy things to the sysroot and do more of the magic that the external toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much simpler. Note that gcc-initial has to be wrapped as well, because it is used for building libc and we want to apply the same magic when building libc. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Fabio Porcedda <fabio.porcedda@gmail.com> Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 14:28:42 +02:00
# Also create <arch>-linux-<tool> symlinks.
define HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
$(Q)cd $(HOST_DIR)/usr/bin; \
for i in $(GNU_TARGET_NAME)-*; do \
case "$$i" in \
*.br_real) \
gcc: use toolchain wrapper We have a toolchain wrapper for external toolchain, but it is also beneficial for internal toolchains, for the following reasons: 1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the compiler even if a package's build system doesn't honor CFLAGS. 2. It allows us to do the unsafe path check (i.e. -I/usr/include) without patching gcc. 3. It makes it simpler to implement building each package with a separate staging directory (per-package staging). 4. It makes it simpler to implement a compiler hash check for ccache. The wrapper is reused from the external toolchain. A third CROSS_PATH_ option is added to the wrapper: in this case, the real executable is in the same directory, with the extension .real. The creation of the simple symlinks is merged with the creation of the wrapper symlinks, otherwise part of the -gcc-ar handling logic would have to be repeated. The complex case-condition could be refactored with the one for the external toolchain, but then it becomes even more complex because they each have special corner cases. For example, the internal toolchain has to handle *.real to avoid creating an extra indirection after host-gcc-{final,initial}-rebuild. Instead of creating the .real files, it would also have been possible to install the internal toolchain in $(HOST_DIR)/opt, similar to what we do for the external toolchain. However, then we would also have to copy things to the sysroot and do more of the magic that the external toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much simpler. Note that gcc-initial has to be wrapped as well, because it is used for building libc and we want to apply the same magic when building libc. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Fabio Porcedda <fabio.porcedda@gmail.com> Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 14:28:42 +02:00
;; \
*-ar|*-ranlib|*-nm) \
ln -snf $$i $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
;; \
*cc|*cc-*|*++|*++-*|*cpp|*-gfortran) \
rm -f $$i.br_real; \
mv $$i $$i.br_real; \
gcc: use toolchain wrapper We have a toolchain wrapper for external toolchain, but it is also beneficial for internal toolchains, for the following reasons: 1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the compiler even if a package's build system doesn't honor CFLAGS. 2. It allows us to do the unsafe path check (i.e. -I/usr/include) without patching gcc. 3. It makes it simpler to implement building each package with a separate staging directory (per-package staging). 4. It makes it simpler to implement a compiler hash check for ccache. The wrapper is reused from the external toolchain. A third CROSS_PATH_ option is added to the wrapper: in this case, the real executable is in the same directory, with the extension .real. The creation of the simple symlinks is merged with the creation of the wrapper symlinks, otherwise part of the -gcc-ar handling logic would have to be repeated. The complex case-condition could be refactored with the one for the external toolchain, but then it becomes even more complex because they each have special corner cases. For example, the internal toolchain has to handle *.real to avoid creating an extra indirection after host-gcc-{final,initial}-rebuild. Instead of creating the .real files, it would also have been possible to install the internal toolchain in $(HOST_DIR)/opt, similar to what we do for the external toolchain. However, then we would also have to copy things to the sysroot and do more of the magic that the external toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much simpler. Note that gcc-initial has to be wrapped as well, because it is used for building libc and we want to apply the same magic when building libc. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Fabio Porcedda <fabio.porcedda@gmail.com> Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 14:28:42 +02:00
ln -sf toolchain-wrapper $$i; \
ln -sf toolchain-wrapper $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
ln -snf $$i.br_real $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}.br_real; \
gcc: use toolchain wrapper We have a toolchain wrapper for external toolchain, but it is also beneficial for internal toolchains, for the following reasons: 1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the compiler even if a package's build system doesn't honor CFLAGS. 2. It allows us to do the unsafe path check (i.e. -I/usr/include) without patching gcc. 3. It makes it simpler to implement building each package with a separate staging directory (per-package staging). 4. It makes it simpler to implement a compiler hash check for ccache. The wrapper is reused from the external toolchain. A third CROSS_PATH_ option is added to the wrapper: in this case, the real executable is in the same directory, with the extension .real. The creation of the simple symlinks is merged with the creation of the wrapper symlinks, otherwise part of the -gcc-ar handling logic would have to be repeated. The complex case-condition could be refactored with the one for the external toolchain, but then it becomes even more complex because they each have special corner cases. For example, the internal toolchain has to handle *.real to avoid creating an extra indirection after host-gcc-{final,initial}-rebuild. Instead of creating the .real files, it would also have been possible to install the internal toolchain in $(HOST_DIR)/opt, similar to what we do for the external toolchain. However, then we would also have to copy things to the sysroot and do more of the magic that the external toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much simpler. Note that gcc-initial has to be wrapped as well, because it is used for building libc and we want to apply the same magic when building libc. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Fabio Porcedda <fabio.porcedda@gmail.com> Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 14:28:42 +02:00
;; \
*) \
ln -snf $$i $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
;; \
esac; \
done
endef
include $(sort $(wildcard package/gcc/*/*.mk))