2013-06-30 21:29:00 +02:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# gcc-initial
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
GCC_INITIAL_VERSION = $(GCC_VERSION)
|
|
|
|
|
GCC_INITIAL_SITE = $(GCC_SITE)
|
|
|
|
|
GCC_INITIAL_SOURCE = $(GCC_SOURCE)
|
|
|
|
|
|
|
|
|
|
HOST_GCC_INITIAL_DEPENDENCIES = $(HOST_GCC_COMMON_DEPENDENCIES)
|
|
|
|
|
|
2013-06-30 21:29:04 +02:00
|
|
|
HOST_GCC_INITIAL_EXTRACT_CMDS = $(HOST_GCC_EXTRACT_CMDS)
|
|
|
|
|
|
2013-06-30 21:29:00 +02:00
|
|
|
ifneq ($(call qstrip, $(BR2_XTENSA_CORE_NAME)),)
|
|
|
|
|
HOST_GCC_INITIAL_POST_EXTRACT_CMDS += HOST_GCC_XTENSA_OVERLAY_EXTRACT
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
HOST_GCC_INITIAL_POST_PATCH_HOOKS += HOST_GCC_APPLY_PATCHES
|
|
|
|
|
|
|
|
|
|
# gcc doesn't support in-tree build, so we create a 'build'
|
|
|
|
|
# subdirectory in the gcc sources, and build from there.
|
|
|
|
|
HOST_GCC_INITIAL_SUBDIR = build
|
|
|
|
|
|
|
|
|
|
HOST_GCC_INITIAL_PRE_CONFIGURE_HOOKS += HOST_GCC_CONFIGURE_SYMLINK
|
|
|
|
|
|
|
|
|
|
HOST_GCC_INITIAL_CONF_OPT = \
|
|
|
|
|
$(HOST_GCC_COMMON_CONF_OPT) \
|
|
|
|
|
--enable-languages=c \
|
|
|
|
|
--disable-shared \
|
|
|
|
|
--without-headers \
|
|
|
|
|
--with-newlib \
|
|
|
|
|
--disable-largefile \
|
gcc: use BR2_EXTRA_GCC_CONFIG_OPTIONS in gcc-initial and gcc-intermediate
When refactoring the internal toolchain backend logic, the code was
changed to pass the custom configure options given through
BR2_EXTRA_GCC_CONFIG_OPTIONS only for the gcc final pass, with the
idea that we're only interested by user customization for the final
compiler.
However, the beaglebone_defconfig was passing --with-float=hard
--with-fpu=vfpv3-d16 as BR2_EXTRA_GCC_CONFIG_OPTIONS, and since the
refactoring, it was causing build failures of the beaglebone_defconfig
(with messages saying that Busybox is built to use VFP arguments, but
libc/libm are not). This is due to the fact that the gcc intermediate,
which is used to build the C library, wasn't built to generate hard
float, while the final compiler was generating hard float.
So, we get back to the original situation where the options in
BR2_EXTRA_GCC_CONFIG_OPTIONS are passed to all of the compiler
passes. Of course, the specific case of hard float will be fixed by
following patches in this area, but the idea still remains: the three
gcc should have the same options, if those options affected the ABI of
the generated code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-14 00:27:24 +02:00
|
|
|
--disable-nls \
|
|
|
|
|
$(call qstrip,$(BR2_EXTRA_GCC_CONFIG_OPTIONS))
|
2013-06-30 21:29:00 +02:00
|
|
|
|
2013-09-04 16:18:14 +02:00
|
|
|
HOST_GCC_INITIAL_CONF_ENV = \
|
|
|
|
|
$(HOST_GCC_COMMON_CONF_ENV)
|
|
|
|
|
|
2013-06-30 21:29:00 +02:00
|
|
|
HOST_GCC_INITIAL_MAKE_OPT = all-gcc
|
|
|
|
|
HOST_GCC_INITIAL_INSTALL_OPT = install-gcc
|
|
|
|
|
|
|
|
|
|
$(eval $(host-autotools-package))
|
