kumquat-buildroot/toolchain/toolchain-external/pkg-toolchain-external.mk

633 lines
26 KiB
Makefile
Raw Normal View History

################################################################################
# External toolchain package infrastructure
#
# This package infrastructure implements the support for external
# toolchains, i.e toolchains that are available pre-built, ready to
# use. Such toolchain may either be readily available on the Web
# (Linaro, Sourcery CodeBench, from processor vendors) or may be built
# with tools like Crosstool-NG or Buildroot itself. So far, we have
# tested this with:
#
# * Toolchains generated by Crosstool-NG
# * Toolchains generated by Buildroot
# * Toolchains provided by Linaro for the ARM and AArch64
# architectures
# * Sourcery CodeBench toolchains (from Mentor Graphics) for the ARM,
# MIPS, PowerPC, x86_64 and NIOS 2 architectures. For the MIPS
# toolchain, the -muclibc variant isn't supported yet, only the
# default glibc-based variant is.
# * Synopsys DesignWare toolchains for ARC cores
#
# The basic principle is the following
#
# 1. If the toolchain is not pre-installed, download and extract it
# in $(TOOLCHAIN_EXTERNAL_INSTALL_DIR). Otherwise,
# $(TOOLCHAIN_EXTERNAL_INSTALL_DIR) points to were the toolchain has
# already been installed by the user.
#
# 2. For all external toolchains, perform some checks on the
# conformity between the toolchain configuration described in the
# Buildroot menuconfig system, and the real configuration of the
# external toolchain. This is for example important to make sure that
# the Buildroot configuration system knows whether the toolchain
# supports RPC, IPv6, locales, large files, etc. Unfortunately, these
# things cannot be detected automatically, since the value of these
# options (such as BR2_TOOLCHAIN_HAS_NATIVE_RPC) are needed at
# configuration time because these options are used as dependencies
# for other options. And at configuration time, we are not able to
# retrieve the external toolchain configuration.
#
# 3. Copy the libraries needed at runtime to the target directory,
# $(TARGET_DIR). Obviously, things such as the C library, the dynamic
# loader and a few other utility libraries are needed if dynamic
# applications are to be executed on the target system.
#
# 4. Copy the libraries and headers to the staging directory. This
# will allow all further calls to gcc to be made using --sysroot
# $(STAGING_DIR), which greatly simplifies the compilation of the
# packages when using external toolchains. So in the end, only the
# cross-compiler binaries remains external, all libraries and headers
# are imported into the Buildroot tree.
#
# 5. Build a toolchain wrapper which executes the external toolchain
# with a number of arguments (sysroot/march/mtune/..) hardcoded,
# so we're sure the correct configuration is always used and the
# toolchain behaves similar to an internal toolchain.
# This toolchain wrapper and symlinks are installed into
# $(HOST_DIR)/bin like for the internal toolchains, and the rest
# of Buildroot is handled identical for the 2 toolchain types.
################################################################################
#
# Definitions of where the toolchain can be found
#
TOOLCHAIN_EXTERNAL_PREFIX = $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PREFIX))
TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR = $(HOST_DIR)/opt/ext-toolchain
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD),y)
TOOLCHAIN_EXTERNAL_INSTALL_DIR = $(TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR)
else
TOOLCHAIN_EXTERNAL_INSTALL_DIR = $(abspath $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PATH)))
endif
ifeq ($(TOOLCHAIN_EXTERNAL_INSTALL_DIR),)
ifneq ($(TOOLCHAIN_EXTERNAL_PREFIX),)
# if no path set, figure it out from path
TOOLCHAIN_EXTERNAL_BIN := $(dir $(shell which $(TOOLCHAIN_EXTERNAL_PREFIX)-gcc))
endif
else
TOOLCHAIN_EXTERNAL_REL_BIN_PATH = $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_REL_BIN_PATH))
ifeq ($(TOOLCHAIN_EXTERNAL_REL_BIN_PATH),)
TOOLCHAIN_EXTERNAL_REL_BIN_PATH = bin
endif
TOOLCHAIN_EXTERNAL_BIN = $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/$(TOOLCHAIN_EXTERNAL_REL_BIN_PATH)
endif
# If this is a buildroot toolchain, it already has a wrapper which we want to
# bypass. Since this is only evaluated after it has been extracted, we can use
# $(wildcard ...) here.
TOOLCHAIN_EXTERNAL_SUFFIX = \
$(if $(wildcard $(TOOLCHAIN_EXTERNAL_BIN)/*.br_real),.br_real)
TOOLCHAIN_EXTERNAL_CROSS = $(TOOLCHAIN_EXTERNAL_BIN)/$(TOOLCHAIN_EXTERNAL_PREFIX)-
TOOLCHAIN_EXTERNAL_CC = $(TOOLCHAIN_EXTERNAL_CROSS)gcc$(TOOLCHAIN_EXTERNAL_SUFFIX)
TOOLCHAIN_EXTERNAL_CXX = $(TOOLCHAIN_EXTERNAL_CROSS)g++$(TOOLCHAIN_EXTERNAL_SUFFIX)
TOOLCHAIN_EXTERNAL_GDC = $(TOOLCHAIN_EXTERNAL_CROSS)gdc$(TOOLCHAIN_EXTERNAL_SUFFIX)
TOOLCHAIN_EXTERNAL_FC = $(TOOLCHAIN_EXTERNAL_CROSS)gfortran$(TOOLCHAIN_EXTERNAL_SUFFIX)
TOOLCHAIN_EXTERNAL_READELF = $(TOOLCHAIN_EXTERNAL_CROSS)readelf
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
# Normal handling of downloaded toolchain tarball extraction.
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD),y)
# As a regular package, the toolchain gets extracted in $(@D), but
# since it's actually a fairly special package, we need it to be moved
# into TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR.
define TOOLCHAIN_EXTERNAL_MOVE
rm -rf $(TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR)
mkdir -p $(TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR)
mv $(@D)/* $(TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR)/
endef
endif
#
# Definitions of the list of libraries that should be copied to the target.
#
toolchain-external: copy ld*.so* for all C libraries Currently, for the dynamic loader, we're copying ld*.so* for glibc and uClibc, except for glibc/EABIhf where we are explicitly copying ld-linux-armhf.so.*. For musl, we're not copying the dynamic linker because it's simply a symbolic link to libc.so. However, the name of the musl dynamic linker changes from one architecture to the other, and we don't handle all cases. Since handling the musl dynamic linker symlink creation is becoming more and more annoying to maintain, this commit makes musl use the same mechanism as glibc/uClibc: put the dynamic linker in TOOLCHAIN_EXTERNAL_LIBS. In addition, the special condition on glibc/EABIhf was added in 11ec38b6950cf3337b52fb97f27c2fd7c776c5c2 ("toolchain-external: fix Linaro ARM toolchain support") because an old Linaro toolchain had two dynamic loaders, and we wanted to copy only one. But 1/ this is old and 2/ having the two dynamic linkers doesn't really matter. So this commit simply unconditionally adds "ld*.so*" to TOOLCHAIN_EXTERNAL_LIBS, regardless of the C library being chosen. It re-uses the musl dynamic linker symlink from the sysroot, which makes it always correct, and allows us to remove the TOOLCHAIN_EXTERNAL_MUSL_LD_LINK hook, and all the related logic. This commit therefore solves two problems with the musl dynamic linker symbolic link creation logic: 1 We support all architectures, without having to hardcode in Buildroot the mapping between the CPU architecture and the corresponding dynamic linker name. For example, our current logic was not handling the mips64+n32 ABI case, where the dynamic linker is named ld-musl-mipsn32el.so.1. 2 We support Crosstool-NG musl toolchains, where the dynamic linker is in /lib, but libc.so is in /usr/lib. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- This commit therefore replaces: - https://patchwork.ozlabs.org/patch/780411/ (was another solution for solving problem 1 above) - https://patchwork.ozlabs.org/patch/763977/ and https://patchwork.ozlabs.org/patch/748974/ (was another solution for solving problem 2 above)
2017-07-02 15:14:17 +02:00
toolchain/toolchain-external: restrict copying of dynamic loader to ld*.so.* Commit 32bec8ee2fb00c6750fa842bbb0eb79b0c081fa2 ("toolchain-external: copy ld*.so* for all C libraries") changed (among other things) the glob pattern to catch the dynamic loader from ld*.so.* to ld*.so* thus now matching files like 'ld-2.20.so' in addition to files like 'ld.so.1'. However, there is no apparent reason why that change was made. It is not explicitly mentioned in the commit message as to why that would be needed, nor is clear based on the rest of the changes in that commit. But it turns out that it causes too many files to be copied with some toolchains. In most toolchains, the structure looks like this: -rwxr-xr-x 1 tdescham tdescham 834364 Feb 16 21:23 output/target/lib/ld-2.16.so lrwxrwxrwx 1 tdescham tdescham 10 Feb 16 21:23 output/target/lib/ld.so.1 -> ld-2.16.so So, a symlink 'ld.so.1' which points to another file. Applications would have 'ld.so.1' (the link) encoded as program interpreter (readelf -l <program>, see INTERP entry) The patterns like 'ld*.so*' are passed as argument to copy_toolchain_lib_root which is defined in toolchain/helpers.mk. This macro copy_toolchain_lib_root will find all files/links matching the pattern. If a match is a regular file, it is simply copied. If it is a symbolic link, the link is copied and then the logic is recursively repeated on the link destination. That destination could either again be a link or a regular file. In the first case we recurse again, in the latter we stop and continue with the next match of the pattern. The problem this patch is solving is when a toolchain does not have this structure with a link and a real file, but rather two actual files: -rwxr-xr-x 1 tdescham tdescham 170892 Feb 16 21:55 output/target/lib/ld-2.20.so -rwxr-xr-x 1 tdescham tdescham 170892 Feb 16 21:55 output/target/lib/ld.so.1 In this case the pattern 'ld*.so*' would find two regular file matches and copy both. On the other hand, the pattern 'ld*.so.*' would only find the 'ld.so.1' file and copy just that. This saves about 170K in rootfs size. Closer inspection reveals that this particular toolchain has more such dedoubled symbolic links, e.g. the standard pattern of 'usr/lib/libfoo.so -> libfoo.so.1 -> libfoo.so.1.0.2' is not present, and each of these three components are real files. In any case, it is obvious that the toolchain itself is 'broken'. That being said, because we have the logic that recursively resolves symbolic links, TOOLCHAIN_EXTERNAL_LIBS really only needs to contain the "initial" name of the library to be copied. Therefore, revert the glob pattern back to what it was. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> [Thomas: improve the commit log with the additional details from Thomas] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 22:15:44 +01:00
TOOLCHAIN_EXTERNAL_LIBS += ld*.so.* libgcc_s.so.* libatomic.so.*
toolchain-external: copy ld*.so* for all C libraries Currently, for the dynamic loader, we're copying ld*.so* for glibc and uClibc, except for glibc/EABIhf where we are explicitly copying ld-linux-armhf.so.*. For musl, we're not copying the dynamic linker because it's simply a symbolic link to libc.so. However, the name of the musl dynamic linker changes from one architecture to the other, and we don't handle all cases. Since handling the musl dynamic linker symlink creation is becoming more and more annoying to maintain, this commit makes musl use the same mechanism as glibc/uClibc: put the dynamic linker in TOOLCHAIN_EXTERNAL_LIBS. In addition, the special condition on glibc/EABIhf was added in 11ec38b6950cf3337b52fb97f27c2fd7c776c5c2 ("toolchain-external: fix Linaro ARM toolchain support") because an old Linaro toolchain had two dynamic loaders, and we wanted to copy only one. But 1/ this is old and 2/ having the two dynamic linkers doesn't really matter. So this commit simply unconditionally adds "ld*.so*" to TOOLCHAIN_EXTERNAL_LIBS, regardless of the C library being chosen. It re-uses the musl dynamic linker symlink from the sysroot, which makes it always correct, and allows us to remove the TOOLCHAIN_EXTERNAL_MUSL_LD_LINK hook, and all the related logic. This commit therefore solves two problems with the musl dynamic linker symbolic link creation logic: 1 We support all architectures, without having to hardcode in Buildroot the mapping between the CPU architecture and the corresponding dynamic linker name. For example, our current logic was not handling the mips64+n32 ABI case, where the dynamic linker is named ld-musl-mipsn32el.so.1. 2 We support Crosstool-NG musl toolchains, where the dynamic linker is in /lib, but libc.so is in /usr/lib. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- This commit therefore replaces: - https://patchwork.ozlabs.org/patch/780411/ (was another solution for solving problem 1 above) - https://patchwork.ozlabs.org/patch/763977/ and https://patchwork.ozlabs.org/patch/748974/ (was another solution for solving problem 2 above)
2017-07-02 15:14:17 +02:00
ifneq ($(BR2_SSP_NONE),y)
TOOLCHAIN_EXTERNAL_LIBS += libssp.so.*
endif
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
TOOLCHAIN_EXTERNAL_LIBS += libc.so.* libcrypt.so.* libdl.so.* libm.so.* libnsl.so.* libresolv.so.* librt.so.* libutil.so.*
ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
TOOLCHAIN_EXTERNAL_LIBS += libpthread.so.*
ifneq ($(BR2_PACKAGE_GDB)$(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY),)
TOOLCHAIN_EXTERNAL_LIBS += libthread_db.so.*
endif # gdbserver
endif # ! no threads
endif
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC),y)
TOOLCHAIN_EXTERNAL_LIBS += libnss_files.so.* libnss_dns.so.* libmvec.so.* libanl.so.*
endif
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_MUSL),y)
TOOLCHAIN_EXTERNAL_LIBS += libc.so
endif
ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
TOOLCHAIN_EXTERNAL_LIBS += libstdc++.so.*
endif
ifeq ($(BR2_TOOLCHAIN_HAS_FORTRAN),y)
TOOLCHAIN_EXTERNAL_LIBS += libgfortran.so.*
# fortran needs quadmath on x86 and x86_64
ifeq ($(BR2_TOOLCHAIN_HAS_LIBQUADMATH),y)
TOOLCHAIN_EXTERNAL_LIBS += libquadmath.so*
endif
endif
ifeq ($(BR2_TOOLCHAIN_HAS_OPENMP),y)
TOOLCHAIN_EXTERNAL_LIBS += libgomp.so.*
endif
ifeq ($(BR2_TOOLCHAIN_HAS_DLANG),y)
TOOLCHAIN_EXTERNAL_LIBS += libgdruntime.so* libgphobos.so*
endif
TOOLCHAIN_EXTERNAL_LIBS += $(addsuffix .so*,$(call qstrip,$(BR2_TOOLCHAIN_EXTRA_LIBS)))
#
# Definition of the CFLAGS to use with the external toolchain, as well as the
# common toolchain wrapper build arguments
#
# march/mtune/floating point mode needs to be passed to the external toolchain
# to select the right multilib variant
ifeq ($(BR2_x86_64),y)
TOOLCHAIN_EXTERNAL_CFLAGS += -m64
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_64
endif
ifneq ($(GCC_TARGET_ARCH),)
TOOLCHAIN_EXTERNAL_CFLAGS += -march=$(GCC_TARGET_ARCH)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_ARCH='"$(GCC_TARGET_ARCH)"'
endif
ifneq ($(GCC_TARGET_CPU),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mcpu=$(GCC_TARGET_CPU)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_CPU='"$(GCC_TARGET_CPU)"'
endif
ifneq ($(GCC_TARGET_ABI),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mabi=$(GCC_TARGET_ABI)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_ABI='"$(GCC_TARGET_ABI)"'
endif
ifeq ($(BR2_TOOLCHAIN_HAS_MNAN_OPTION),y)
ifneq ($(GCC_TARGET_NAN),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mnan=$(GCC_TARGET_NAN)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_NAN='"$(GCC_TARGET_NAN)"'
endif
endif
ifneq ($(GCC_TARGET_FP32_MODE),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mfp$(GCC_TARGET_FP32_MODE)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_FP32_MODE='"$(GCC_TARGET_FP32_MODE)"'
endif
ifneq ($(GCC_TARGET_FPU),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mfpu=$(GCC_TARGET_FPU)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_FPU='"$(GCC_TARGET_FPU)"'
endif
ifneq ($(GCC_TARGET_FLOAT_ABI),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mfloat-abi=$(GCC_TARGET_FLOAT_ABI)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_FLOAT_ABI='"$(GCC_TARGET_FLOAT_ABI)"'
endif
ifneq ($(GCC_TARGET_MODE),)
TOOLCHAIN_EXTERNAL_CFLAGS += -m$(GCC_TARGET_MODE)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_MODE='"$(GCC_TARGET_MODE)"'
endif
ifeq ($(BR2_BINFMT_FLAT),y)
TOOLCHAIN_EXTERNAL_CFLAGS += -Wl,-elf2flt
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_BINFMT_FLAT
endif
ifeq ($(BR2_mipsel)$(BR2_mips64el),y)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_MIPS_TARGET_LITTLE_ENDIAN
TOOLCHAIN_EXTERNAL_CFLAGS += -EL
endif
ifeq ($(BR2_mips)$(BR2_mips64),y)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_MIPS_TARGET_BIG_ENDIAN
TOOLCHAIN_EXTERNAL_CFLAGS += -EB
endif
ifeq ($(BR2_arceb),y)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_ARC_TARGET_BIG_ENDIAN
TOOLCHAIN_EXTERNAL_CFLAGS += -EB
endif
TOOLCHAIN_EXTERNAL_CFLAGS += $(call qstrip,$(BR2_TARGET_OPTIMIZATION))
ifeq ($(BR2_SOFT_FLOAT),y)
TOOLCHAIN_EXTERNAL_CFLAGS += -msoft-float
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_SOFTFLOAT=1
endif
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += \
-DBR_CROSS_PATH_SUFFIX='"$(TOOLCHAIN_EXTERNAL_SUFFIX)"'
ifeq ($(filter $(HOST_DIR)/%,$(TOOLCHAIN_EXTERNAL_BIN)),)
# TOOLCHAIN_EXTERNAL_BIN points outside HOST_DIR => absolute path
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += \
-DBR_CROSS_PATH_ABS='"$(TOOLCHAIN_EXTERNAL_BIN)"'
else
# TOOLCHAIN_EXTERNAL_BIN points inside HOST_DIR => relative path
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += \
-DBR_CROSS_PATH_REL='"$(TOOLCHAIN_EXTERNAL_BIN:$(HOST_DIR)/%=%)"'
endif
#
# The following functions creates the symbolic links needed to get the
# cross-compilation tools visible in $(HOST_DIR)/bin. Some of
# links are done directly to the corresponding tool in the external
# toolchain installation directory, while some other links are done to
# the toolchain wrapper (preprocessor, C, C++ and Fortran compiler)
#
# We skip gdb symlink when we are building our own gdb to prevent two
# gdb's in $(HOST_DIR)/bin.
#
# 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.
define TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER
$(Q)cd $(HOST_DIR)/bin; \
for i in $(TOOLCHAIN_EXTERNAL_CROSS)*; do \
base=$${i##*/}; \
case "$$base" in \
*-ar|*-ranlib|*-nm) \
Eliminate $(HOST_DIR)/usr We currently use $(HOST_DIR)/usr as the prefix for host packages. That has a few disadvantages: - There are some things installed in $(HOST_DIR)/etc and $(HOST_DIR)/sbin, which is inconsistent. - To pack a buildroot-built toolchain into a tarball for use as an external toolchain, you have to pack output/host/usr instead of the more obvious output/host. - Because of the above, the internal toolchain wrapper breaks which forces us to work around it (call the actual toolchain executable directly). This is OK for us, but when used in another build system, that's a problem. - Paths are four characters longer. To allow us to gradually eliminate $(HOST_DIR)/usr while building packages, replace it with a symlink to . The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and $(HOST_DIR)/usr/lib that were added previously are removed again. Note that the symlink creation will break when $(HOST_DIR)/usr already exists as a directory, i.e. when rebuilding in an existing output directory. This is necessary: if we don't break it now, the following commits (which remove the usr part from various variables) _will_ break it. At the same time as creating this symlink, we have to update the external toolchain wrapper and the external toolchain symlinks to go one directory less up. Indeed, $(HOST_DIR) is one level less up than it was before. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-04 16:03:53 +02:00
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%..%') .; \
;; \
*cc|*cc-*|*++|*++-*|*cpp|*-gfortran|*-gdc) \
ln -sf toolchain-wrapper $$base; \
;; \
*gdb|*gdbtui) \
if test "$(BR2_PACKAGE_HOST_GDB)" != "y"; then \
Eliminate $(HOST_DIR)/usr We currently use $(HOST_DIR)/usr as the prefix for host packages. That has a few disadvantages: - There are some things installed in $(HOST_DIR)/etc and $(HOST_DIR)/sbin, which is inconsistent. - To pack a buildroot-built toolchain into a tarball for use as an external toolchain, you have to pack output/host/usr instead of the more obvious output/host. - Because of the above, the internal toolchain wrapper breaks which forces us to work around it (call the actual toolchain executable directly). This is OK for us, but when used in another build system, that's a problem. - Paths are four characters longer. To allow us to gradually eliminate $(HOST_DIR)/usr while building packages, replace it with a symlink to . The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and $(HOST_DIR)/usr/lib that were added previously are removed again. Note that the symlink creation will break when $(HOST_DIR)/usr already exists as a directory, i.e. when rebuilding in an existing output directory. This is necessary: if we don't break it now, the following commits (which remove the usr part from various variables) _will_ break it. At the same time as creating this symlink, we have to update the external toolchain wrapper and the external toolchain symlinks to go one directory less up. Indeed, $(HOST_DIR) is one level less up than it was before. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-04 16:03:53 +02:00
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%..%') .; \
fi \
;; \
*) \
Eliminate $(HOST_DIR)/usr We currently use $(HOST_DIR)/usr as the prefix for host packages. That has a few disadvantages: - There are some things installed in $(HOST_DIR)/etc and $(HOST_DIR)/sbin, which is inconsistent. - To pack a buildroot-built toolchain into a tarball for use as an external toolchain, you have to pack output/host/usr instead of the more obvious output/host. - Because of the above, the internal toolchain wrapper breaks which forces us to work around it (call the actual toolchain executable directly). This is OK for us, but when used in another build system, that's a problem. - Paths are four characters longer. To allow us to gradually eliminate $(HOST_DIR)/usr while building packages, replace it with a symlink to . The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and $(HOST_DIR)/usr/lib that were added previously are removed again. Note that the symlink creation will break when $(HOST_DIR)/usr already exists as a directory, i.e. when rebuilding in an existing output directory. This is necessary: if we don't break it now, the following commits (which remove the usr part from various variables) _will_ break it. At the same time as creating this symlink, we have to update the external toolchain wrapper and the external toolchain symlinks to go one directory less up. Indeed, $(HOST_DIR) is one level less up than it was before. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-04 16:03:53 +02:00
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%..%') .; \
;; \
esac; \
done
endef
# Various utility functions used by the external toolchain package
# infrastructure. Those functions are mainly responsible for:
#
# - installation the toolchain libraries to $(TARGET_DIR)
# - copying the toolchain sysroot to $(STAGING_DIR)
# - installing a gdbinit file
#
# Details about sysroot directory selection.
#
# To find the sysroot directory, we use the trick of looking for the
# 'libc.a' file with the -print-file-name gcc option, and then
# mangling the path to find the base directory of the sysroot.
#
# Note that we do not use the -print-sysroot option, because it is
# only available since gcc 4.4.x, and we only recently dropped support
# for 4.2.x and 4.3.x.
#
# When doing this, we don't pass any option to gcc that could select a
# multilib variant (such as -march) as we want the "main" sysroot,
# which contains all variants of the C library in the case of multilib
# toolchains. We use the TARGET_CC_NO_SYSROOT variable, which is the
# path of the cross-compiler, without the --sysroot=$(STAGING_DIR),
# since what we want to find is the location of the original toolchain
# sysroot. This "main" sysroot directory is stored in SYSROOT_DIR.
#
# Then, multilib toolchains are a little bit more complicated, since
# they in fact have multiple sysroots, one for each variant supported
# by the toolchain. So we need to find the particular sysroot we're
# interested in.
#
# To do so, we ask the compiler where its sysroot is by passing all
# flags (including -march and al.), except the --sysroot flag since we
# want to the compiler to tell us where its original sysroot
# is. ARCH_SUBDIR will contain the subdirectory, in the main
# SYSROOT_DIR, that corresponds to the selected architecture
# variant. ARCH_SYSROOT_DIR will contain the full path to this
# location.
#
# One might wonder why we don't just bother with ARCH_SYSROOT_DIR. The
# fact is that in multilib toolchains, the header files are often only
# present in the main sysroot, and only the libraries are available in
# each variant-specific sysroot directory.
# toolchain_find_sysroot returns the sysroot location for the given
# compiler + flags. We need to handle cases where libc.a is in:
#
# - lib/
# - usr/lib/
# - lib32/
# - lib64/
# - lib32-fp/ (Cavium toolchain)
# - lib64-fp/ (Cavium toolchain)
# - usr/lib/<tuple>/ (Linaro toolchain)
#
# And variations on these.
define toolchain_find_sysroot
$$(printf $(call toolchain_find_libc_a,$(1)) | sed -r -e 's:/(usr/)?lib(32|64)?([^/]*)?/([^/]*/)?libc\.a:/:')
endef
# Returns the lib subdirectory for the given compiler + flags (i.e
# typically lib32 or lib64 for some toolchains)
define toolchain_find_libdir
toolchain-external: cover multilib toolchains with lib/<variant> layout The toolchain from the Cavium Octeon SDK has a sysroot layout as follows: ./lib32 ./lib32/octeon2 ./lib32-fp ./lib64 ./lib64/octeon2 ./lib64-fp ./usr ./usr/lib ./usr/lib32 ./usr/lib32/octeon2 ./usr/lib32-fp ./usr/lib64 ./usr/lib64/octeon2 ./usr/lib64-fp ./usr/bin ./usr/bin32 ./usr/bin32-fp ./usr/bin64-fp ./usr/libexec ./usr/libexec32 ./usr/libexec32-fp ./usr/libexec64-fp ./usr/sbin ./usr/sbin32 ./usr/sbin32-fp ./usr/sbin64-fp ./usr/include ./usr/share ./sbin ./sbin32 ./sbin32-fp ./sbin64-fp ./etc ./var with the following selections: - lib64 : default - lib64/octeon2 : -march=octeon2 - lib64-fp : -march=octeon3 - lib32 : -mabi=n32 - lib32/octeon2 : -mabi=n32 -march=octeon2 - lib32-fp : -mabi=n32 -march=octeon3 In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the original Buildroot toolchain logic would copy both the libraries in lib32 as the subdirectory lib32/octeon2, which means that every library is installed twice (but only one of each is really needed). While ARCH_LIB_DIR is determined by the location of libc.a, which in this case is effectively: <sysroot>/usr/lib32/octeon2/libc.a the variable only retains 'lib32' and not 'lib32/octeon2' as expected. To make Buildroot cope with this style of toolchain layout, we need to adapt the calculation of ARCH_LIB_DIR to also include the second part. This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a singular path component, resulting in some additional changes. Certain older Linaro toolchains actually had the same layout. Libraries were located in lib/<tuple> rather than lib directly. Previously, this was handled by adding a toolchain-specific fixup that creates a symlink lib/<tuple> -> lib, but with this patch this would no longer be needed. Note that one difference with the Octeon case is that these Linaro toolchains are not actually multilib, i.e. there is just one location with the libraries and thus there is no problem with duplicated libraries. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:43 +01:00
$$(printf $(call toolchain_find_libc_a,$(1)) | sed -r -e 's:.*/(usr/)?(lib(32|64)?([^/]*)?(/[^/]*)?)/libc.a:\2:')
endef
# Returns the location of the libc.a file for the given compiler + flags
define toolchain_find_libc_a
$$(readlink -f $$(LANG=C $(1) -print-file-name=libc.a))
endef
# Integration of the toolchain into Buildroot: find the main sysroot
# and the variant-specific sysroot, then copy the needed libraries to
# the $(TARGET_DIR) and copy the whole sysroot (libraries and headers)
# to $(STAGING_DIR).
#
# Variables are defined as follows:
#
# SYSROOT_DIR: the main sysroot directory, deduced from the location of
# the libc.a file in the default multilib variant, by
# removing the usr/lib[32|64]/libc.a part of the path.
# Ex: /x-tools/mips-2011.03/mips-linux-gnu/libc/
#
# ARCH_SYSROOT_DIR: the sysroot of the selected multilib variant,
# deduced from the location of the libc.a file in the
# selected multilib variant (taking into account the
# CFLAGS), by removing usr/lib[32|64]/libc.a at the end
# of the path.
# Ex: /x-tools/mips-2011.03/mips-linux-gnu/libc/mips16/soft-float/el/
#
# ARCH_LIB_DIR: 'lib', 'lib32' or 'lib64' depending on where libraries
# are stored. Deduced from the location of the libc.a file
# in the selected multilib variant, by looking at
# usr/lib??/libc.a.
# Ex: lib
#
# ARCH_SUBDIR: the relative location of the sysroot of the selected
# multilib variant compared to the main sysroot.
# Ex: mips16/soft-float/el
#
# SUPPORT_LIB_DIR: some toolchains, such as recent Linaro toolchains,
# store GCC support libraries (libstdc++,
# libgcc_s, etc.) outside of the sysroot. In
# this case, SUPPORT_LIB_DIR is set to a
# non-empty value, and points to the directory
# where these support libraries are
# available. Those libraries will be copied to
# our sysroot, and the directory will also be
# considered when searching libraries for copy
# to the target filesystem.
#
# Please be very careful to check the major toolchain sources:
# Buildroot, Crosstool-NG, CodeSourcery and Linaro
# before doing any modification on the below logic.
ifeq ($(BR2_STATIC_LIBS),)
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS
$(Q)$(call MESSAGE,"Copying external toolchain libraries to target...")
$(Q)for libpattern in $(TOOLCHAIN_EXTERNAL_LIBS); do \
$(call copy_toolchain_lib_root,$$libpattern); \
done
endef
endif
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY),y)
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER
$(Q)$(call MESSAGE,"Copying gdbserver")
$(Q)ARCH_SYSROOT_DIR="$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
ARCH_LIB_DIR="$(call toolchain_find_libdir,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
gdbserver_found=0 ; \
for d in $${ARCH_SYSROOT_DIR}/usr \
$${ARCH_SYSROOT_DIR}/../debug-root/usr \
$${ARCH_SYSROOT_DIR}/usr/$${ARCH_LIB_DIR} \
$(TOOLCHAIN_EXTERNAL_INSTALL_DIR); do \
if test -f $${d}/bin/gdbserver ; then \
install -m 0755 -D $${d}/bin/gdbserver $(TARGET_DIR)/usr/bin/gdbserver ; \
gdbserver_found=1 ; \
break ; \
fi ; \
done ; \
if [ $${gdbserver_found} -eq 0 ] ; then \
echo "Could not find gdbserver in external toolchain" ; \
exit 1 ; \
fi
endef
endif
define TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS
$(Q)SYSROOT_DIR="$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC))" ; \
ARCH_SYSROOT_DIR="$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
ARCH_LIB_DIR="$(call toolchain_find_libdir,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
SUPPORT_LIB_DIR="" ; \
if test `find $${ARCH_SYSROOT_DIR} -name 'libstdc++.a' | wc -l` -eq 0 ; then \
LIBSTDCPP_A_LOCATION=$$(LANG=C $(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS) -print-file-name=libstdc++.a) ; \
if [ -e "$${LIBSTDCPP_A_LOCATION}" ]; then \
SUPPORT_LIB_DIR=`readlink -f $${LIBSTDCPP_A_LOCATION} | sed -r -e 's:libstdc\+\+\.a::'` ; \
fi ; \
fi ; \
if [ "$${SYSROOT_DIR}" == "$${ARCH_SYSROOT_DIR}" ] ; then \
ARCH_SUBDIR="" ; \
elif [ "`dirname $${ARCH_SYSROOT_DIR}`" = "`dirname $${SYSROOT_DIR}`" ] ; then \
SYSROOT_DIR_DIRNAME=`dirname $${SYSROOT_DIR}`/ ; \
ARCH_SUBDIR=`echo $${ARCH_SYSROOT_DIR} | sed -r -e "s:^$${SYSROOT_DIR_DIRNAME}(.*)/$$:\1:"` ; \
else \
ARCH_SUBDIR=`echo $${ARCH_SYSROOT_DIR} | sed -r -e "s:^$${SYSROOT_DIR}(.*)/$$:\1:"` ; \
fi ; \
$(call MESSAGE,"Copying external toolchain sysroot to staging...") ; \
$(call copy_toolchain_sysroot,$${SYSROOT_DIR},$${ARCH_SYSROOT_DIR},$${ARCH_SUBDIR},$${ARCH_LIB_DIR},$${SUPPORT_LIB_DIR})
endef
# Create a symlink from (usr/)$(ARCH_LIB_DIR) to lib.
# Note: the skeleton package additionally creates lib32->lib or lib64->lib
# (as appropriate)
#
# $1: destination directory (TARGET_DIR / STAGING_DIR)
create_lib_symlinks = \
$(Q)DESTDIR="$(strip $1)" ; \
ARCH_LIB_DIR="$(call toolchain_find_libdir,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
if [ ! -e "$${DESTDIR}/$${ARCH_LIB_DIR}" -a ! -e "$${DESTDIR}/usr/$${ARCH_LIB_DIR}" ]; then \
toolchain-external: cover multilib toolchains with lib/<variant> layout The toolchain from the Cavium Octeon SDK has a sysroot layout as follows: ./lib32 ./lib32/octeon2 ./lib32-fp ./lib64 ./lib64/octeon2 ./lib64-fp ./usr ./usr/lib ./usr/lib32 ./usr/lib32/octeon2 ./usr/lib32-fp ./usr/lib64 ./usr/lib64/octeon2 ./usr/lib64-fp ./usr/bin ./usr/bin32 ./usr/bin32-fp ./usr/bin64-fp ./usr/libexec ./usr/libexec32 ./usr/libexec32-fp ./usr/libexec64-fp ./usr/sbin ./usr/sbin32 ./usr/sbin32-fp ./usr/sbin64-fp ./usr/include ./usr/share ./sbin ./sbin32 ./sbin32-fp ./sbin64-fp ./etc ./var with the following selections: - lib64 : default - lib64/octeon2 : -march=octeon2 - lib64-fp : -march=octeon3 - lib32 : -mabi=n32 - lib32/octeon2 : -mabi=n32 -march=octeon2 - lib32-fp : -mabi=n32 -march=octeon3 In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the original Buildroot toolchain logic would copy both the libraries in lib32 as the subdirectory lib32/octeon2, which means that every library is installed twice (but only one of each is really needed). While ARCH_LIB_DIR is determined by the location of libc.a, which in this case is effectively: <sysroot>/usr/lib32/octeon2/libc.a the variable only retains 'lib32' and not 'lib32/octeon2' as expected. To make Buildroot cope with this style of toolchain layout, we need to adapt the calculation of ARCH_LIB_DIR to also include the second part. This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a singular path component, resulting in some additional changes. Certain older Linaro toolchains actually had the same layout. Libraries were located in lib/<tuple> rather than lib directly. Previously, this was handled by adding a toolchain-specific fixup that creates a symlink lib/<tuple> -> lib, but with this patch this would no longer be needed. Note that one difference with the Octeon case is that these Linaro toolchains are not actually multilib, i.e. there is just one location with the libraries and thus there is no problem with duplicated libraries. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:43 +01:00
relpath="$(call relpath_prefix,$${ARCH_LIB_DIR})" ; \
ln -snf $${relpath}lib "$${DESTDIR}/$${ARCH_LIB_DIR}" ; \
ln -snf $${relpath}lib "$${DESTDIR}/usr/$${ARCH_LIB_DIR}" ; \
fi
define TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK
$(call create_lib_symlinks,$(STAGING_DIR))
endef
define TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK
$(call create_lib_symlinks,$(TARGET_DIR))
endef
#
# Generate gdbinit file for use with Buildroot
#
define TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT
$(Q)if test -f $(TARGET_CROSS)gdb ; then \
$(call MESSAGE,"Installing gdbinit"); \
$(gen_gdbinit_file); \
fi
endef
# GCC installs a libstdcxx-...so-gdb.py file that gdb will load automatically,
# but it contains hardcoded paths referring to the location where the (external)
# toolchain was built. Fix up these paths so that the pretty printers can be
# loaded automatically.
# By default, the pretty printers are installed in
# $(datadir)/gcc-$(gcc_version)/python but this could have been overwritten with
# the gcc configure option: --with-python-dir. We thus have to search the
# correct path first.
define TOOLCHAIN_EXTERNAL_FIXUP_PRETTY_PRINTER_LOADER
$(Q)loadfiles=$$(find $(STAGING_DIR) -name 'libstdc++.so*-gdb.py' 2>/dev/null); \
pythondir=$$(find $(TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR) -path '*/libstdcxx/__init__.py' 2>/dev/null | sed 's%/libstdcxx/__init__.py%%' | head -n1); \
if [ -n "$$loadfiles" ] && [ -n "$$pythondir" ]; then \
echo "Fixing up hardcoded paths in GDB pretty-printer auto-load file(s) for libstdcxx: $$loadfiles"; \
sed -ri \
-e 's%^libdir\s*=.*%libdir = "$(STAGING_DIR)/lib"%' \
-e "s%^pythondir\s*=.*%pythondir = '$$pythondir'%" \
$$loadfiles; \
fi
endef
# uClibc-ng dynamic loader is called ld-uClibc.so.1, but gcc is not
# patched specifically for uClibc-ng, so it continues to generate
# binaries that expect the dynamic loader to be named ld-uClibc.so.0,
# like with the original uClibc. Therefore, we create an additional
# symbolic link to make uClibc-ng systems work properly.
define TOOLCHAIN_EXTERNAL_FIXUP_UCLIBCNG_LDSO
$(Q)if test -e $(TARGET_DIR)/lib/ld-uClibc.so.1; then \
ln -sf ld-uClibc.so.1 $(TARGET_DIR)/lib/ld-uClibc.so.0 ; \
fi
$(Q)if test -e $(TARGET_DIR)/lib/ld64-uClibc.so.1; then \
ln -sf ld64-uClibc.so.1 $(TARGET_DIR)/lib/ld64-uClibc.so.0 ; \
fi
endef
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LDD
$(Q)if test -f $(STAGING_DIR)/usr/bin/ldd ; then \
$(INSTALL) -D $(STAGING_DIR)/usr/bin/ldd $(TARGET_DIR)/usr/bin/ldd ; \
$(SED) 's:.*/bin/bash:#!/bin/sh:' $(TARGET_DIR)/usr/bin/ldd ; \
fi
endef
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
################################################################################
# inner-toolchain-external-package -- defines the generic installation rules
# for external toolchain packages
#
# argument 1 is the lowercase package name
# argument 2 is the uppercase package name, including a HOST_ prefix
# for host packages
# argument 3 is the uppercase package name, without the HOST_ prefix
# for host packages
# argument 4 is the type (target or host)
################################################################################
define inner-toolchain-external-package
$(2)_INSTALL_STAGING = YES
$(2)_ADD_TOOLCHAIN_DEPENDENCY = NO
# In fact, we don't need to download the toolchain, since it is already
# available on the system, so force the site and source to be empty so
# that nothing will be downloaded/extracted.
ifeq ($$(BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED),y)
$(2)_SITE =
$(2)_SOURCE =
endif
ifeq ($$(BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD),y)
$(2)_EXCLUDES = usr/lib/locale/*
$(2)_POST_EXTRACT_HOOKS += \
TOOLCHAIN_EXTERNAL_MOVE
endif
# Checks for an already installed toolchain: check the toolchain
# location, check that it is usable, and then verify that it
# matches the configuration provided in Buildroot: ABI, C++ support,
# kernel headers version, type of C library and all C library features.
define $(2)_CONFIGURE_CMDS
$$(Q)$$(call check_cross_compiler_exists,$$(TOOLCHAIN_EXTERNAL_CC))
$$(Q)$$(call check_unusable_toolchain,$$(TOOLCHAIN_EXTERNAL_CC))
$$(Q)SYSROOT_DIR="$$(call toolchain_find_sysroot,$$(TOOLCHAIN_EXTERNAL_CC))" ; \
$$(call check_kernel_headers_version,\
$$(BUILD_DIR),\
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
$$(call toolchain_find_sysroot,$$(TOOLCHAIN_EXTERNAL_CC)),\
$$(call qstrip,$$(BR2_TOOLCHAIN_HEADERS_AT_LEAST)),\
$$(if $$(BR2_TOOLCHAIN_EXTERNAL_CUSTOM),loose,strict)); \
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
$$(call check_gcc_version,$$(TOOLCHAIN_EXTERNAL_CC),\
$$(call qstrip,$$(BR2_TOOLCHAIN_GCC_AT_LEAST))); \
if test "$$(BR2_arm)" = "y" ; then \
$$(call check_arm_abi,\
"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)") ; \
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
fi ; \
if test "$$(BR2_INSTALL_LIBSTDCPP)" = "y" ; then \
$$(call check_cplusplus,$$(TOOLCHAIN_EXTERNAL_CXX)) ; \
fi ; \
if test "$$(BR2_TOOLCHAIN_HAS_DLANG)" = "y" ; then \
$$(call check_dlang,$$(TOOLCHAIN_EXTERNAL_GDC)) ; \
fi ; \
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
if test "$$(BR2_TOOLCHAIN_HAS_FORTRAN)" = "y" ; then \
$$(call check_fortran,$$(TOOLCHAIN_EXTERNAL_FC)) ; \
fi ; \
if test "$$(BR2_TOOLCHAIN_HAS_OPENMP)" = "y" ; then \
$$(call check_openmp,$$(TOOLCHAIN_EXTERNAL_CC)) ; \
fi ; \
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
if test "$$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC)" = "y" ; then \
$$(call check_uclibc,$$$${SYSROOT_DIR}) ; \
elif test "$$(BR2_TOOLCHAIN_EXTERNAL_MUSL)" = "y" ; then \
$$(call check_musl,\
"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)") ; \
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
else \
$$(call check_glibc,$$$${SYSROOT_DIR}) ; \
fi
$$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION))
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
endef
$(2)_TOOLCHAIN_WRAPPER_ARGS += $$(TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS)
$(2)_BUILD_CMDS = $$(TOOLCHAIN_WRAPPER_BUILD)
define $(2)_INSTALL_STAGING_CMDS
$$(TOOLCHAIN_WRAPPER_INSTALL)
$$(TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK)
$$(TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS)
$$(TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER)
$$(TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT)
$$(TOOLCHAIN_EXTERNAL_FIXUP_PRETTY_PRINTER_LOADER)
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
endef
# Even though we're installing things in both the staging, the host
# and the target directory, we do everything within the
# install-staging step, arbitrarily.
define $(2)_INSTALL_TARGET_CMDS
$$(TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK)
$$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS)
$$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER)
$$(TOOLCHAIN_EXTERNAL_FIXUP_UCLIBCNG_LDSO)
$$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LDD)
toolchain-external: introduce toolchain-external-package The toolchain-external-package infrastructure is just a copy of the toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2) and adding double-dollars everywhere. toolchain-external itself is converted to a virtual package, but it is faked a little to make sue the toolchains that haven't been converted to toolchain-external-package yet keep on working. The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined for every toolchain-external-package instance, so that is moved out into the common part of pkg-toolchain-external.mk. The musl-compat-headers dependency stays in the toolchain-external package itself. The musl ld link is duplicated in the legacy toolchain-external and the toolchain-external-package, because they have separate hooks. The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention, because its value will be different for different toolchain-external-package instances. However, the value only depends on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in the generic part. So we don't have to do anything specific for this variable after all. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-07 02:19:59 +01:00
endef
# Call the generic package infrastructure to generate the necessary
# make targets
$(call inner-generic-package,$(1),$(2),$(3),$(4))
endef
toolchain-external-package = $(call inner-toolchain-external-package,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)