2013-06-30 21:28:59 +02:00
|
|
|
################################################################################
|
|
|
|
|
#
|
2014-09-14 11:50:00 +02:00
|
|
|
# Common variables for the gcc-initial and gcc-final packages.
|
2013-06-30 21:28:59 +02:00
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Version, site and source
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
GCC_VERSION = $(call qstrip,$(BR2_GCC_VERSION))
|
|
|
|
|
|
2015-02-14 10:23:11 +01:00
|
|
|
ifeq ($(BR2_arc),y)
|
2013-12-05 18:20:49 +01:00
|
|
|
GCC_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,gcc,$(GCC_VERSION))
|
|
|
|
|
GCC_SOURCE = gcc-$(GCC_VERSION).tar.gz
|
2017-01-25 07:35:07 +01:00
|
|
|
else ifeq ($(BR2_or1k),y)
|
|
|
|
|
GCC_SITE = $(call github,openrisc,or1k-gcc,$(GCC_VERSION))
|
|
|
|
|
GCC_SOURCE = gcc-$(GCC_VERSION).tar.gz
|
2014-04-30 00:27:51 +02:00
|
|
|
else
|
2013-06-30 21:28:59 +02:00
|
|
|
GCC_SITE = $(BR2_GNU_MIRROR:/=)/gcc/gcc-$(GCC_VERSION)
|
2017-01-25 07:35:07 +01:00
|
|
|
GCC_SOURCE = gcc-$(GCC_VERSION).tar.bz2
|
2013-06-30 21:28:59 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# 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
|
|
|
|
|
|
2013-06-30 21:28:59 +02:00
|
|
|
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
|
2013-06-30 21:28:59 +02:00
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Apply patches
|
|
|
|
|
#
|
|
|
|
|
|
gcc: remove BR2_GCC_SHARED_LIBGCC option
Commit 6b48b4803450 ("add a know to enable/disable building a shared
libgcc"), from october 2006, isn't really as to why a
BR2_GCC_SHARED_LIBGCC option was needed. However, now that gcc has
been converted to the package infrastructure, it causes problems
because the host packages are always being passed --enable-shared
--disable-static, so re-adding --disable-shared on top of that break
things.
Moreover, our tests indicate that both a shared *and* a static version
of libgcc are built, and that linking dynamically and statically a
program that uses libgcc_s gives correct results: dynamically linked
against libgcc_s in the first case, statically linked in the second
case.
Therefore, it appears that this option is no longer necessary, and
removing it has the advantage of fixing the builds of
qemu_mips64_malta_defconfig and qemu_sparc_ss10_defconfig, both of
which had BR2_GCC_SHARED_LIBGCC not enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-08 17:59:45 +02:00
|
|
|
ifeq ($(ARCH),powerpc)
|
2013-07-05 10:40:52 +02:00
|
|
|
ifneq ($(BR2_SOFT_FLOAT),)
|
|
|
|
|
define HOST_GCC_APPLY_POWERPC_PATCH
|
2014-10-27 01:26:10 +01:00
|
|
|
$(APPLY_PATCHES) $(@D) package/gcc/$(GCC_VERSION) 1000-powerpc-link-with-math-lib.patch.conditional
|
2013-07-05 10:40:52 +02:00
|
|
|
endef
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2016-04-13 06:20:32 +02:00
|
|
|
# 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.
|
2013-06-30 21:28:59 +02:00
|
|
|
define HOST_GCC_APPLY_PATCHES
|
2016-04-13 06:20:32 +02:00
|
|
|
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
|
2013-07-05 10:40:52 +02:00
|
|
|
$(HOST_GCC_APPLY_POWERPC_PATCH)
|
2013-06-30 21:28:59 +02:00
|
|
|
endef
|
|
|
|
|
|
2015-11-04 08:32:39 +01:00
|
|
|
HOST_GCC_EXCLUDES = \
|
2015-10-24 14:48:55 +02:00
|
|
|
libjava/* libgo/* \
|
|
|
|
|
gcc/testsuite/* libstdc++-v3/testsuite/*
|
2013-06-30 21:29:04 +02:00
|
|
|
|
2015-10-24 14:48:55 +02:00
|
|
|
define HOST_GCC_FAKE_TESTSUITE
|
2013-06-30 21:29:04 +02:00
|
|
|
mkdir -p $(@D)/libstdc++-v3/testsuite/
|
|
|
|
|
echo "all:" > $(@D)/libstdc++-v3/testsuite/Makefile.in
|
|
|
|
|
echo "install:" >> $(@D)/libstdc++-v3/testsuite/Makefile.in
|
|
|
|
|
endef
|
|
|
|
|
|
2013-06-30 21:28:59 +02:00
|
|
|
#
|
|
|
|
|
# Create 'build' directory and configure symlink
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
define HOST_GCC_CONFIGURE_SYMLINK
|
|
|
|
|
mkdir -p $(@D)/build
|
2013-09-02 18:06:35 +02:00
|
|
|
ln -sf ../configure $(@D)/build/configure
|
2013-06-30 21:28:59 +02:00
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Common configuration options
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
HOST_GCC_COMMON_DEPENDENCIES = \
|
|
|
|
|
host-binutils \
|
|
|
|
|
host-gmp \
|
2016-10-16 09:11:31 +02:00
|
|
|
host-mpc \
|
2013-09-11 14:12:06 +02:00
|
|
|
host-mpfr \
|
|
|
|
|
$(if $(BR2_BINFMT_FLAT),host-elf2flt)
|
2013-06-30 21:28:59 +02:00
|
|
|
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS = \
|
2013-06-30 21:28:59 +02:00
|
|
|
--target=$(GNU_TARGET_NAME) \
|
|
|
|
|
--with-sysroot=$(STAGING_DIR) \
|
|
|
|
|
--disable-__cxa_atexit \
|
|
|
|
|
--with-gnu-ld \
|
|
|
|
|
--disable-libssp \
|
|
|
|
|
--disable-multilib \
|
|
|
|
|
--with-gmp=$(HOST_DIR)/usr \
|
2016-10-16 09:11:31 +02:00
|
|
|
--with-mpc=$(HOST_DIR)/usr \
|
2015-03-03 17:44:04 +01:00
|
|
|
--with-mpfr=$(HOST_DIR)/usr \
|
|
|
|
|
--with-pkgversion="Buildroot $(BR2_VERSION_FULL)" \
|
|
|
|
|
--with-bugurl="http://bugs.buildroot.net/"
|
2013-09-04 16:18:14 +02:00
|
|
|
|
|
|
|
|
# Don't build documentation. It takes up extra space / build time,
|
|
|
|
|
# and sometimes needs specific makeinfo versions to work
|
|
|
|
|
HOST_GCC_COMMON_CONF_ENV = \
|
2013-09-03 15:22:17 +02:00
|
|
|
MAKEINFO=missing
|
2013-06-30 21:28:59 +02:00
|
|
|
|
2015-03-24 14:55:15 +01:00
|
|
|
GCC_COMMON_TARGET_CFLAGS = $(TARGET_CFLAGS)
|
|
|
|
|
GCC_COMMON_TARGET_CXXFLAGS = $(TARGET_CXXFLAGS)
|
|
|
|
|
|
|
|
|
|
# Propagate options used for target software building to GCC target libs
|
2015-07-23 23:08:55 +02:00
|
|
|
HOST_GCC_COMMON_CONF_ENV += CFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CFLAGS)"
|
2015-03-24 14:55:15 +01:00
|
|
|
HOST_GCC_COMMON_CONF_ENV += CXXFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CXXFLAGS)"
|
|
|
|
|
|
2015-01-15 01:29:44 +01:00
|
|
|
# libitm needs sparc V9+
|
|
|
|
|
ifeq ($(BR2_sparc_v8)$(BR2_sparc_leon3),y)
|
|
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --disable-libitm
|
|
|
|
|
endif
|
|
|
|
|
|
2016-10-23 00:04:22 +02:00
|
|
|
# libmpx uses secure_getenv and struct _libc_fpstate not present in musl
|
|
|
|
|
ifeq ($(BR2_TOOLCHAIN_BUILDROOT_MUSL)$(BR2_TOOLCHAIN_GCC_AT_LEAST_6),yy)
|
|
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --disable-libmpx
|
|
|
|
|
endif
|
|
|
|
|
|
2016-06-27 17:11:15 +02:00
|
|
|
# quadmath support requires wchar
|
2016-07-03 15:47:38 +02:00
|
|
|
ifeq ($(BR2_USE_WCHAR)$(BR2_TOOLCHAIN_HAS_LIBQUADMATH),yy)
|
|
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --enable-libquadmath
|
|
|
|
|
else
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --disable-libquadmath
|
2013-06-30 21:28:59 +02:00
|
|
|
endif
|
|
|
|
|
|
2014-05-05 23:17:09 +02:00
|
|
|
# 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)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --disable-libsanitizer
|
2014-04-24 03:00:32 +02:00
|
|
|
endif
|
|
|
|
|
|
2015-04-15 21:41:56 +02:00
|
|
|
# libsanitizer is broken for SPARC
|
|
|
|
|
# https://bugs.busybox.net/show_bug.cgi?id=7951
|
2015-10-11 19:17:27 +02:00
|
|
|
ifeq ($(BR2_sparc)$(BR2_sparc64),y)
|
2015-04-15 21:41:56 +02:00
|
|
|
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)
|
2014-09-27 21:32:44 +02:00
|
|
|
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
|
2013-06-30 21:28:59 +02:00
|
|
|
endif
|
|
|
|
|
|
2015-03-06 13:34:06 +01:00
|
|
|
ifeq ($(BR2_GCC_ENABLE_LTO),y)
|
|
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --enable-plugins --enable-lto
|
|
|
|
|
endif
|
|
|
|
|
|
2013-09-02 18:06:38 +02:00
|
|
|
ifeq ($(BR2_GCC_ENABLE_LIBMUDFLAP),y)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --enable-libmudflap
|
2013-09-02 18:06:38 +02:00
|
|
|
else
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --disable-libmudflap
|
2013-09-02 18:06:38 +02:00
|
|
|
endif
|
|
|
|
|
|
2013-06-30 21:28:59 +02:00
|
|
|
ifeq ($(BR2_PTHREADS_NONE),y)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += \
|
2013-06-30 21:28:59 +02:00
|
|
|
--disable-threads \
|
|
|
|
|
--disable-libitm \
|
|
|
|
|
--disable-libatomic
|
|
|
|
|
else
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --enable-threads
|
2013-06-30 21:28:59 +02:00
|
|
|
endif
|
|
|
|
|
|
2014-05-19 21:48:13 +02:00
|
|
|
ifeq ($(BR2_GCC_ENABLE_GRAPHITE),y)
|
2015-12-07 08:31:31 +01:00
|
|
|
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
|
2014-05-19 21:48:13 +02:00
|
|
|
else
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --without-isl --without-cloog
|
2014-05-19 21:48:13 +02:00
|
|
|
endif
|
|
|
|
|
|
2017-01-28 10:19:28 +01:00
|
|
|
ifeq ($(BR2_arc)$(BR2_or1k),y)
|
2013-06-30 21:28:59 +02:00
|
|
|
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)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --with-float=soft
|
2013-06-30 21:28:59 +02:00
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE),y)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --disable-decimal-float
|
2013-06-30 21:28:59 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# Determine arch/tune/abi/cpu options
|
2016-06-03 06:03:02 +02:00
|
|
|
ifeq ($(BR2_GCC_ARCH_HAS_CONFIGURABLE_DEFAULTS),y)
|
2013-06-30 21:28:59 +02:00
|
|
|
ifneq ($(call qstrip,$(BR2_GCC_TARGET_ARCH)),)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --with-arch=$(BR2_GCC_TARGET_ARCH)
|
2013-06-30 21:28:59 +02:00
|
|
|
endif
|
|
|
|
|
ifneq ($(call qstrip,$(BR2_GCC_TARGET_ABI)),)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --with-abi=$(BR2_GCC_TARGET_ABI)
|
2013-06-30 21:28:59 +02:00
|
|
|
endif
|
|
|
|
|
ifneq ($(call qstrip,$(BR2_GCC_TARGET_CPU)),)
|
|
|
|
|
ifneq ($(call qstrip,$(BR2_GCC_TARGET_CPU_REVISION)),)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --with-cpu=$(call qstrip,$(BR2_GCC_TARGET_CPU)-$(BR2_GCC_TARGET_CPU_REVISION))
|
2013-06-30 21:28:59 +02:00
|
|
|
else
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --with-cpu=$(call qstrip,$(BR2_GCC_TARGET_CPU))
|
2013-06-30 21:28:59 +02:00
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
arch: introduce BR2_GCC_TARGET_{FPU, FLOAT_ABI}
Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.
This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:12 +02:00
|
|
|
GCC_TARGET_FPU = $(call qstrip,$(BR2_GCC_TARGET_FPU))
|
|
|
|
|
ifneq ($(GCC_TARGET_FPU),)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --with-fpu=$(GCC_TARGET_FPU)
|
arch: introduce BR2_GCC_TARGET_{FPU, FLOAT_ABI}
Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.
This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:12 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
GCC_TARGET_FLOAT_ABI = $(call qstrip,$(BR2_GCC_TARGET_FLOAT_ABI))
|
|
|
|
|
ifneq ($(GCC_TARGET_FLOAT_ABI),)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --with-float=$(GCC_TARGET_FLOAT_ABI)
|
arch: introduce BR2_GCC_TARGET_{FPU, FLOAT_ABI}
Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.
This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:12 +02:00
|
|
|
endif
|
|
|
|
|
|
2013-07-16 10:03:22 +02:00
|
|
|
GCC_TARGET_MODE = $(call qstrip,$(BR2_GCC_TARGET_MODE))
|
|
|
|
|
ifneq ($(GCC_TARGET_MODE),)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += --with-mode=$(GCC_TARGET_MODE)
|
2013-07-16 10:03:22 +02:00
|
|
|
endif
|
2016-06-03 06:03:02 +02:00
|
|
|
endif # BR2_GCC_ARCH_HAS_CONFIGURABLE_DEFAULTS
|
2013-07-16 10:03:22 +02:00
|
|
|
|
2013-09-02 18:06:38 +02:00
|
|
|
# Enable proper double/long double for SPE ABI
|
2013-06-30 21:28:59 +02:00
|
|
|
ifeq ($(BR2_powerpc_SPE),y)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_COMMON_CONF_OPTS += \
|
2013-06-30 21:28:59 +02:00
|
|
|
--enable-e500_double \
|
|
|
|
|
--with-long-double-128
|
|
|
|
|
endif
|
|
|
|
|
|
2016-08-18 08:37:29 +02:00
|
|
|
# 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
|
|
|
|
|
|
2015-10-14 23:05:54 +02:00
|
|
|
HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".br_real"'
|
2016-06-03 06:03:02 +02:00
|
|
|
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
|
|
|
|
2015-10-17 15:09:09 +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)
|
2016-04-13 06:20:32 +02:00
|
|
|
|
|
|
|
|
# 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 += \
|
2015-10-04 19:26:03 +02:00
|
|
|
$(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 \
|
2016-07-03 18:00:10 +02:00
|
|
|
$(addsuffix /$($(PKG)_RAWNAME)/$(GCC_VERSION)/*.patch,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR))) \
|
|
|
|
|
$(addsuffix /$($(PKG)_RAWNAME)/*.patch,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR))) \
|
2016-04-13 06:20:32 +02:00
|
|
|
$(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
|
|
|
|
|
|
2015-10-04 18:06:01 +02:00
|
|
|
# _CONF_OPTS contains some references to the absolute path of $(HOST_DIR)
|
|
|
|
|
# and a reference to the Buildroot git revision (BR2_VERSION_FULL),
|
2015-10-04 17:25:32 +02:00
|
|
|
# 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=\"`\
|
2015-10-04 18:06:01 +02:00
|
|
|
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.
|
2016-07-01 18:29:07 +02:00
|
|
|
# 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.
|
2015-10-14 23:05:54 +02:00
|
|
|
# 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 \
|
2015-10-14 23:05:54 +02:00
|
|
|
*.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)}; \
|
|
|
|
|
;; \
|
2016-07-01 18:29:07 +02:00
|
|
|
*cc|*cc-*|*++|*++-*|*cpp|*-gfortran) \
|
2015-10-14 23:05:54 +02:00
|
|
|
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)}; \
|
2015-10-14 23:05:54 +02:00
|
|
|
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
|
|
|
|
|
|
2013-09-03 10:45:41 +02:00
|
|
|
include $(sort $(wildcard package/gcc/*/*.mk))
|
