kumquat-buildroot/package/gcc/gcc.mk

295 lines
8.8 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
define HOST_GCC_APPLY_PATCHES
if test -d package/gcc/$(GCC_VERSION); then \
$(APPLY_PATCHES) $(@D) package/gcc/$(GCC_VERSION) \*.patch ; \
fi;
$(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-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-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
# gcc 4.6.x quadmath requires wchar
ifneq ($(BR2_TOOLCHAIN_BUILDROOT_WCHAR),y)
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
ifeq ($(BR2_GCC_ENABLE_TLS),y)
HOST_GCC_COMMON_CONF_OPTS += --enable-tls
else
HOST_GCC_COMMON_CONF_OPTS += --disable-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_NEEDS_MPC),y)
HOST_GCC_COMMON_DEPENDENCIES += host-mpc
HOST_GCC_COMMON_CONF_OPTS += --with-mpc=$(HOST_DIR)/usr
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
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
# 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
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".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
# 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
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)))))
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.
# 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) \
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))