2013-06-30 21:29:02 +02:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# gcc-final
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
GCC_FINAL_VERSION = $(GCC_VERSION)
|
.mk files: bulk aligment and whitespace cleanup of assignments
The Buildroot coding style defines one space around make assignments and
does not align the assignment symbols.
This patch does a bulk fix of offending packages. The package
infrastructures (or more in general assignments to calculated variable
names, like $(2)_FOO) are not touched.
Alignment of line continuation characters (\) is kept as-is.
The sed command used to do this replacement is:
find * -name "*.mk" | xargs sed -i \
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*$#\1 \2#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\]\+\)$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\ \t]\+\s*\\\)\s*$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\(\s*\\\)#\1 \2\3#'
Brief explanation of this command:
^\([A-Z0-9a-z_]\+\) a regular variable at the beginning of the line
\([?:+]\?=\) any assignment character =, :=, ?=, +=
\([^\\]\+\) any string not containing a line continuation
\([^\\ \t]\+\s*\\\) string, optional whitespace, followed by a
line continuation character
\(\s*\\\) optional whitespace, followed by a line
continuation character
Hence, the first subexpression handles empty assignments, the second
handles regular assignments, the third handles regular assignments with
line continuation, and the fourth empty assignments with line
continuation.
This expression was tested on following test text: (initial tab not
included)
FOO = spaces before
FOO = spaces before and after
FOO = tab before
FOO = tab and spaces before
FOO = tab after
FOO = tab and spaces after
FOO = spaces and tab after
FOO = \
FOO = bar \
FOO = bar space \
FOO = \
GENIMAGE_DEPENDENCIES = host-pkgconf libconfuse
FOO += spaces before
FOO ?= spaces before and after
FOO :=
FOO =
FOO =
FOO =
FOO =
$(MAKE1) CROSS_COMPILE=$(TARGET_CROSS) -C
AT91BOOTSTRAP3_DEFCONFIG = \
AXEL_DISABLE_I18N=--i18n=0
After this bulk change, following manual fixups were done:
- fix line continuation alignment in cegui06 and spice (the sed
expression leaves the number of whitespace between the value and line
continuation character intact, but the whitespace before that could have
changed, causing misalignment.
- qt5base was reverted, as this package uses extensive alignment which
actually makes the code more readable.
Finally, the end result was manually reviewed.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Yann E. Morin <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-07 09:06:03 +02:00
|
|
|
GCC_FINAL_SITE = $(GCC_SITE)
|
|
|
|
|
GCC_FINAL_SOURCE = $(GCC_SOURCE)
|
2013-06-30 21:29:02 +02:00
|
|
|
|
2018-04-02 16:57:58 +02:00
|
|
|
HOST_GCC_FINAL_DL_SUBDIR = gcc
|
|
|
|
|
|
2013-06-30 21:29:02 +02:00
|
|
|
HOST_GCC_FINAL_DEPENDENCIES = \
|
|
|
|
|
$(HOST_GCC_COMMON_DEPENDENCIES) \
|
2014-02-04 15:03:06 +01:00
|
|
|
$(BR_LIBC)
|
2013-06-30 21:29:02 +02:00
|
|
|
|
2015-11-04 08:32:39 +01:00
|
|
|
HOST_GCC_FINAL_EXCLUDES = $(HOST_GCC_EXCLUDES)
|
2013-06-30 21:29:04 +02:00
|
|
|
|
arch/xtensa: allow specifying path to tarball file
currently, specifying a custom Xtrensa core is done with two variables:
- the core name
- the directory containing the overlay tarball
However, the core name only serves to construct the tarball name, and is
not used whatsoever to configure any of the toolchain components
(binutils, gcc or gdb), except through the files that are overlayed in
their respective source trees.
This has two main drawbacks:
- the overlay file must be named after the core,
- the tarball can not be compressed.
Furthermore, it also makes it extremely complex to implement a download
of that tarball.
So, those two variables can be squeezed into a single variable, that is
the complete path of the overlay tarball.
Update the qemu-xtensa defconfig accordingly.
Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it
was previously a blind option in the last release, and there's been no
release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the
legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user
could have seen in any of our releases so far.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 14:21:56 +02:00
|
|
|
ifneq ($(ARCH_XTENSA_OVERLAY_FILE),)
|
2014-02-27 06:07:20 +01:00
|
|
|
HOST_GCC_FINAL_POST_EXTRACT_HOOKS += HOST_GCC_XTENSA_OVERLAY_EXTRACT
|
2017-07-09 14:21:58 +02:00
|
|
|
HOST_GCC_FINAL_EXTRA_DOWNLOADS += $(ARCH_XTENSA_OVERLAY_URL)
|
2013-06-30 21:29:02 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
HOST_GCC_FINAL_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_FINAL_SUBDIR = build
|
|
|
|
|
|
2013-09-02 18:06:34 +02:00
|
|
|
HOST_GCC_FINAL_PRE_CONFIGURE_HOOKS += HOST_GCC_CONFIGURE_SYMLINK
|
2013-06-30 21:29:02 +02:00
|
|
|
|
2015-11-22 15:39:42 +01:00
|
|
|
# We want to always build the static variants of all the gcc libraries,
|
|
|
|
|
# of which libstdc++, libgomp, libmudflap...
|
|
|
|
|
# To do so, we can not just pass --enable-static to override the generic
|
|
|
|
|
# --disable-static flag, otherwise gcc fails to build some of those
|
|
|
|
|
# libraries, see;
|
|
|
|
|
# http://lists.busybox.net/pipermail/buildroot/2013-October/080412.html
|
|
|
|
|
#
|
|
|
|
|
# So we must completely override the generic commands and provide our own.
|
|
|
|
|
#
|
2021-11-29 07:27:03 +01:00
|
|
|
define HOST_GCC_FINAL_CONFIGURE_CMDS
|
2014-10-25 20:29:31 +02:00
|
|
|
(cd $(HOST_GCC_FINAL_SRCDIR) && rm -rf config.cache; \
|
|
|
|
|
$(HOST_CONFIGURE_OPTS) \
|
|
|
|
|
CFLAGS="$(HOST_CFLAGS)" \
|
|
|
|
|
LDFLAGS="$(HOST_LDFLAGS)" \
|
|
|
|
|
$(HOST_GCC_FINAL_CONF_ENV) \
|
|
|
|
|
./configure \
|
2017-07-05 13:14:18 +02:00
|
|
|
--prefix="$(HOST_DIR)" \
|
2014-10-25 20:29:31 +02:00
|
|
|
--sysconfdir="$(HOST_DIR)/etc" \
|
|
|
|
|
--enable-static \
|
|
|
|
|
$(QUIET) $(HOST_GCC_FINAL_CONF_OPTS) \
|
|
|
|
|
)
|
2013-10-10 11:40:42 +02:00
|
|
|
endef
|
|
|
|
|
|
2013-06-30 21:29:02 +02:00
|
|
|
# Languages supported by the cross-compiler
|
|
|
|
|
GCC_FINAL_CROSS_LANGUAGES-y = c
|
|
|
|
|
GCC_FINAL_CROSS_LANGUAGES-$(BR2_INSTALL_LIBSTDCPP) += c++
|
2019-10-24 20:16:20 +02:00
|
|
|
GCC_FINAL_CROSS_LANGUAGES-$(BR2_TOOLCHAIN_BUILDROOT_DLANG) += d
|
2015-05-09 19:40:54 +02:00
|
|
|
GCC_FINAL_CROSS_LANGUAGES-$(BR2_TOOLCHAIN_BUILDROOT_FORTRAN) += fortran
|
2013-06-30 21:29:02 +02:00
|
|
|
GCC_FINAL_CROSS_LANGUAGES = $(subst $(space),$(comma),$(GCC_FINAL_CROSS_LANGUAGES-y))
|
|
|
|
|
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_FINAL_CONF_OPTS = \
|
|
|
|
|
$(HOST_GCC_COMMON_CONF_OPTS) \
|
2013-06-30 21:29:02 +02:00
|
|
|
--enable-languages=$(GCC_FINAL_CROSS_LANGUAGES) \
|
2017-07-04 16:03:58 +02:00
|
|
|
--with-build-time-tools=$(HOST_DIR)/$(GNU_TARGET_NAME)/bin
|
2013-06-30 21:29:02 +02:00
|
|
|
|
sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.
So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.
Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.
Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(ARM and SH4 uClibc toolchain builds)
2015-04-08 10:54:55 +02:00
|
|
|
# The kernel wants to use the -m4-nofpu option to make sure that it
|
|
|
|
|
# doesn't use floating point operations.
|
|
|
|
|
ifeq ($(BR2_sh4)$(BR2_sh4eb),y)
|
|
|
|
|
HOST_GCC_FINAL_CONF_OPTS += "--with-multilib-list=m4,m4-nofpu"
|
2017-07-04 16:03:58 +02:00
|
|
|
HOST_GCC_FINAL_GCC_LIB_DIR = $(HOST_DIR)/$(GNU_TARGET_NAME)/lib/!m4*
|
2019-10-26 10:45:58 +02:00
|
|
|
else ifeq ($(BR2_sh4a)$(BR2_sh4aeb),y)
|
sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.
So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.
Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.
Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(ARM and SH4 uClibc toolchain builds)
2015-04-08 10:54:55 +02:00
|
|
|
HOST_GCC_FINAL_CONF_OPTS += "--with-multilib-list=m4a,m4a-nofpu"
|
2017-07-04 16:03:58 +02:00
|
|
|
HOST_GCC_FINAL_GCC_LIB_DIR = $(HOST_DIR)/$(GNU_TARGET_NAME)/lib/!m4*
|
2019-10-26 10:45:58 +02:00
|
|
|
else
|
|
|
|
|
HOST_GCC_FINAL_GCC_LIB_DIR = $(HOST_DIR)/$(GNU_TARGET_NAME)/lib*
|
sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.
So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.
Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.
Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(ARM and SH4 uClibc toolchain builds)
2015-04-08 10:54:55 +02:00
|
|
|
endif
|
|
|
|
|
|
2018-10-21 13:54:14 +02:00
|
|
|
ifeq ($(BR2_GCC_SUPPORTS_LIBCILKRTS),y)
|
|
|
|
|
|
2017-08-04 23:44:54 +02:00
|
|
|
# libcilkrts does not support v8
|
|
|
|
|
ifeq ($(BR2_sparc),y)
|
|
|
|
|
HOST_GCC_FINAL_CONF_OPTS += --disable-libcilkrts
|
|
|
|
|
endif
|
|
|
|
|
|
2018-10-21 13:54:13 +02:00
|
|
|
# Pthreads are required to build libcilkrts
|
|
|
|
|
ifeq ($(BR2_PTHREADS_NONE),y)
|
|
|
|
|
HOST_GCC_FINAL_CONF_OPTS += --disable-libcilkrts
|
|
|
|
|
endif
|
|
|
|
|
|
2018-10-21 13:54:14 +02:00
|
|
|
ifeq ($(BR2_STATIC_LIBS),y)
|
|
|
|
|
# disable libcilkrts as there is no static version
|
|
|
|
|
HOST_GCC_FINAL_CONF_OPTS += --disable-libcilkrts
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
endif # BR2_GCC_SUPPORTS_LIBCILKRTS
|
|
|
|
|
|
2014-05-26 00:12:57 +02:00
|
|
|
# Disable shared libs like libstdc++ if we do static since it confuses linking
|
2014-12-03 22:41:29 +01:00
|
|
|
ifeq ($(BR2_STATIC_LIBS),y)
|
2018-10-21 13:54:14 +02:00
|
|
|
HOST_GCC_FINAL_CONF_OPTS += --disable-shared
|
2014-05-26 00:12:57 +02:00
|
|
|
else
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_FINAL_CONF_OPTS += --enable-shared
|
2014-05-26 00:12:57 +02:00
|
|
|
endif
|
|
|
|
|
|
2013-06-30 21:29:02 +02:00
|
|
|
ifeq ($(BR2_GCC_ENABLE_OPENMP),y)
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_FINAL_CONF_OPTS += --enable-libgomp
|
2013-06-30 21:29:02 +02:00
|
|
|
else
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_FINAL_CONF_OPTS += --disable-libgomp
|
2013-06-30 21:29:02 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# End with user-provided options, so that they can override previously
|
|
|
|
|
# defined options.
|
2014-09-27 21:32:44 +02:00
|
|
|
HOST_GCC_FINAL_CONF_OPTS += \
|
2013-06-30 21:29:02 +02:00
|
|
|
$(call qstrip,$(BR2_EXTRA_GCC_CONFIG_OPTIONS))
|
|
|
|
|
|
2013-09-04 16:18:14 +02:00
|
|
|
HOST_GCC_FINAL_CONF_ENV = \
|
|
|
|
|
$(HOST_GCC_COMMON_CONF_ENV)
|
|
|
|
|
|
2015-10-17 15:09:09 +02:00
|
|
|
HOST_GCC_FINAL_MAKE_OPTS += $(HOST_GCC_COMMON_MAKE_OPTS)
|
|
|
|
|
|
2013-06-30 21:29:02 +02:00
|
|
|
# Make sure we have 'cc'
|
|
|
|
|
define HOST_GCC_FINAL_CREATE_CC_SYMLINKS
|
2017-07-04 16:03:58 +02:00
|
|
|
if [ ! -e $(HOST_DIR)/bin/$(GNU_TARGET_NAME)-cc ]; then \
|
|
|
|
|
ln -f $(HOST_DIR)/bin/$(GNU_TARGET_NAME)-gcc \
|
|
|
|
|
$(HOST_DIR)/bin/$(GNU_TARGET_NAME)-cc; \
|
2013-06-30 21:29:02 +02:00
|
|
|
fi
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_FINAL_CREATE_CC_SYMLINKS
|
|
|
|
|
|
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
|
|
|
HOST_GCC_FINAL_TOOLCHAIN_WRAPPER_ARGS += $(HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS)
|
2016-09-28 10:00:56 +02:00
|
|
|
HOST_GCC_FINAL_POST_BUILD_HOOKS += TOOLCHAIN_WRAPPER_BUILD
|
|
|
|
|
HOST_GCC_FINAL_POST_INSTALL_HOOKS += TOOLCHAIN_WRAPPER_INSTALL
|
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
|
|
|
# Note: this must be done after CREATE_CC_SYMLINKS, otherwise the
|
|
|
|
|
# -cc symlink to the wrapper is not created.
|
|
|
|
|
HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
|
2013-06-30 21:29:02 +02:00
|
|
|
|
2016-04-29 19:51:23 +02:00
|
|
|
# coldfire is not working without removing these object files from libgcc.a
|
|
|
|
|
ifeq ($(BR2_m68k_cf),y)
|
|
|
|
|
define HOST_GCC_FINAL_M68K_LIBGCC_FIXUP
|
|
|
|
|
find $(STAGING_DIR) -name libgcc.a -print | \
|
|
|
|
|
while read t; do $(GNU_TARGET_NAME)-ar dv "$t" _ctors.o; done
|
|
|
|
|
endef
|
|
|
|
|
HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_FINAL_M68K_LIBGCC_FIXUP
|
|
|
|
|
endif
|
|
|
|
|
|
2013-06-30 21:29:02 +02:00
|
|
|
# Cannot use the HOST_GCC_FINAL_USR_LIBS mechanism below, because we want
|
2014-02-04 16:36:18 +01:00
|
|
|
# libgcc_s to be installed in /lib and not /usr/lib.
|
2013-06-30 21:29:02 +02:00
|
|
|
define HOST_GCC_FINAL_INSTALL_LIBGCC
|
sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.
So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.
Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.
Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(ARM and SH4 uClibc toolchain builds)
2015-04-08 10:54:55 +02:00
|
|
|
-cp -dpf $(HOST_GCC_FINAL_GCC_LIB_DIR)/libgcc_s* \
|
2013-06-30 21:29:02 +02:00
|
|
|
$(STAGING_DIR)/lib/
|
sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.
So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.
Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.
Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(ARM and SH4 uClibc toolchain builds)
2015-04-08 10:54:55 +02:00
|
|
|
-cp -dpf $(HOST_GCC_FINAL_GCC_LIB_DIR)/libgcc_s* \
|
2013-06-30 21:29:02 +02:00
|
|
|
$(TARGET_DIR)/lib/
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_FINAL_INSTALL_LIBGCC
|
|
|
|
|
|
2015-04-19 11:48:16 +02:00
|
|
|
define HOST_GCC_FINAL_INSTALL_LIBATOMIC
|
2015-06-05 02:28:47 +02:00
|
|
|
-cp -dpf $(HOST_GCC_FINAL_GCC_LIB_DIR)/libatomic* \
|
2015-04-19 11:48:16 +02:00
|
|
|
$(STAGING_DIR)/lib/
|
2015-06-05 02:28:47 +02:00
|
|
|
-cp -dpf $(HOST_GCC_FINAL_GCC_LIB_DIR)/libatomic* \
|
2015-04-19 11:48:16 +02:00
|
|
|
$(TARGET_DIR)/lib/
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_FINAL_INSTALL_LIBATOMIC
|
|
|
|
|
|
2013-06-30 21:29:02 +02:00
|
|
|
# Handle the installation of libraries in /usr/lib
|
|
|
|
|
HOST_GCC_FINAL_USR_LIBS =
|
|
|
|
|
|
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 ($(BR2_INSTALL_LIBSTDCPP),y)
|
2013-06-30 21:29:02 +02:00
|
|
|
HOST_GCC_FINAL_USR_LIBS += libstdc++
|
|
|
|
|
endif
|
|
|
|
|
|
2019-10-24 20:16:20 +02:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_BUILDROOT_DLANG),y)
|
|
|
|
|
HOST_GCC_FINAL_USR_LIBS += libgdruntime libgphobos
|
|
|
|
|
endif
|
|
|
|
|
|
2015-05-09 19:40:54 +02:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_BUILDROOT_FORTRAN),y)
|
|
|
|
|
HOST_GCC_FINAL_USR_LIBS += libgfortran
|
2016-07-03 15:47:39 +02:00
|
|
|
# fortran needs quadmath on x86 and x86_64
|
|
|
|
|
ifeq ($(BR2_TOOLCHAIN_HAS_LIBQUADMATH),y)
|
|
|
|
|
HOST_GCC_FINAL_USR_LIBS += libquadmath
|
|
|
|
|
endif
|
2015-05-09 19:40:54 +02:00
|
|
|
endif
|
|
|
|
|
|
2013-06-30 21:29:02 +02:00
|
|
|
ifeq ($(BR2_GCC_ENABLE_OPENMP),y)
|
|
|
|
|
HOST_GCC_FINAL_USR_LIBS += libgomp
|
|
|
|
|
endif
|
|
|
|
|
|
2019-10-27 21:59:02 +01:00
|
|
|
HOST_GCC_FINAL_USR_LIBS += $(call qstrip,$(BR2_TOOLCHAIN_EXTRA_LIBS))
|
|
|
|
|
|
2013-06-30 21:29:02 +02:00
|
|
|
ifneq ($(HOST_GCC_FINAL_USR_LIBS),)
|
2014-05-26 00:12:57 +02:00
|
|
|
define HOST_GCC_FINAL_INSTALL_STATIC_LIBS
|
2013-06-30 21:29:02 +02:00
|
|
|
for i in $(HOST_GCC_FINAL_USR_LIBS) ; do \
|
sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.
So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.
Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.
Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(ARM and SH4 uClibc toolchain builds)
2015-04-08 10:54:55 +02:00
|
|
|
cp -dpf $(HOST_GCC_FINAL_GCC_LIB_DIR)/$${i}.a \
|
2013-10-10 11:40:42 +02:00
|
|
|
$(STAGING_DIR)/usr/lib/ ; \
|
2014-05-26 00:12:57 +02:00
|
|
|
done
|
|
|
|
|
endef
|
|
|
|
|
|
2014-12-03 22:41:29 +01:00
|
|
|
ifeq ($(BR2_STATIC_LIBS),)
|
2014-05-26 00:12:57 +02:00
|
|
|
define HOST_GCC_FINAL_INSTALL_SHARED_LIBS
|
|
|
|
|
for i in $(HOST_GCC_FINAL_USR_LIBS) ; do \
|
sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.
So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.
Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.
Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(ARM and SH4 uClibc toolchain builds)
2015-04-08 10:54:55 +02:00
|
|
|
cp -dpf $(HOST_GCC_FINAL_GCC_LIB_DIR)/$${i}.so* \
|
2014-05-26 00:12:57 +02:00
|
|
|
$(STAGING_DIR)/usr/lib/ ; \
|
sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.
So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.
Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.
Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(ARM and SH4 uClibc toolchain builds)
2015-04-08 10:54:55 +02:00
|
|
|
cp -dpf $(HOST_GCC_FINAL_GCC_LIB_DIR)/$${i}.so* \
|
2013-06-30 21:29:02 +02:00
|
|
|
$(TARGET_DIR)/usr/lib/ ; \
|
|
|
|
|
done
|
|
|
|
|
endef
|
2014-05-26 00:12:57 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
define HOST_GCC_FINAL_INSTALL_USR_LIBS
|
|
|
|
|
mkdir -p $(TARGET_DIR)/usr/lib
|
|
|
|
|
$(HOST_GCC_FINAL_INSTALL_STATIC_LIBS)
|
|
|
|
|
$(HOST_GCC_FINAL_INSTALL_SHARED_LIBS)
|
|
|
|
|
endef
|
2013-06-30 21:29:02 +02:00
|
|
|
HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_FINAL_INSTALL_USR_LIBS
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
$(eval $(host-autotools-package))
|
