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

797 lines
36 KiB
Makefile
Raw Normal View History

################################################################################
#
# toolchain-external
#
################################################################################
#
# This package 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:
external-toolchain: Support for multilib toolchains Multilib toolchains provide different versions of the base libraries for different architecture variants. For example, the ARM Codesourcery toolchain provides base libraries for ARMv5 (default), ARMv4t and Thumb2. Depending on the -march= argument passed to gcc, the sysroot used by the compiler is therefore different. This means that the sysroot location in CROSS-gcc -v cannot be used. Instead, we must use CROSS-gcc -print-sysroot when available and fall back to the old way if unavailable. Moreover, we cannot simply copy the full sysroot as we used to do, because the sysroot organization of multilib toolchain is more complicated. In Codesourcery toolchains, we have : / etc -- for ARMv5 lib -- for ARMv5 sbin -- for ARMv5 usr -- for ARMv5 (includes headers) armv4t etc -- for ARMv4t lib -- for ARMv4t sbin -- for ARMv4t usr -- for ARMv4t (no headers!) thumb2 etc -- for Thumb2 lib -- for Thumb2 sbin -- for Thumb2 usr -- for Thumb2 (no headers!) So we have the default ARMv5 architecture variant that is installed in the main directory, and we have subdirectories for the ARMv4t and Thumb2 architecture variants. Copying the full sysroot to the staging directory doesn't work. All our packages are based on the fact that they should install libraries in staging/usr/lib. But if ARMv4t is used, the compiler would only look in staging/armv4t/usr/lib for libraries (even when overriding the sysroot with the --sysroot option, the multilib compiler suffixes the sysroot directory with the architecture variant if it matches a recognized one). Therefore, we have to copy only the sysroot that we are interested in. This is rendered a little bit complicated by the fact that the armv4t and thumb2 sysroot do not contain the headers since they are shared with the armv5 sysroot. So, this patch : * Modifies how we compute SYSROOT_DIR in order to use -print-sysroot if it exists. SYSROOT_DIR contains the location of the main sysroot directory, i.e the sysroot for the default architecture variant. * Defines ARCH_SUBDIR as the subdirectory in the main sysroot for the currently selected architecture variant (in our case, it can be ".", "armv4t" or "thumb2"). ARCH_SYSROOT_DIR is defined as the full path to the sysroot of the currently selected architecture variant. * Modifies copy_toolchain_lib_root (which copies a library to the target/ directory) so that libraries are taken from ARCH_SYSROOT_DIR instead of SYSROOT_DIR. This ensures that libraries for the correct architecture variant are properly copied to the target. * Modifies copy_toolchain_sysroot (which copies the sysroot to the staging/ directory), so that it copies the contents of ARCH_SYSROOT_DIR, and if needed, adds the headers from the main sysroot directory and a symbolic link (armv4t -> . or thumb2 -> .) to make the compiler believe that its sysroot is really in armv4t/ or thumb2/. Tested with Codesourcery 2009q1 ARM toolchain, Crosstool-NG ARM glibc and ARM uClibc toolchains. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2009-08-22 01:13:22 +02:00
#
# * 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, x86_64 and NIOS 2 architectures. For the MIPS
# toolchain, the -muclibc variant isn't supported yet, only the
# default glibc-based variant is.
# * Analog Devices toolchains for the Blackfin architecture
# * Xilinx toolchains for the Microblaze architecture
# * 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)/usr/bin like for the internal toolchains, and the rest
# of Buildroot is handled identical for the 2 toolchain types.
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
TOOLCHAIN_EXTERNAL_LIBS += libatomic.so.* libc.so.* libcrypt.so.* libdl.so.* libgcc_s.so.* libm.so.* libnsl.so.* libresolv.so.* librt.so.* libutil.so.*
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_ARM_EABIHF),yy)
TOOLCHAIN_EXTERNAL_LIBS += ld-linux-armhf.so.*
else
TOOLCHAIN_EXTERNAL_LIBS += ld*.so.*
endif
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.*
endif
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_MUSL),y)
TOOLCHAIN_EXTERNAL_LIBS += libc.so libgcc_s.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
TOOLCHAIN_EXTERNAL_LIBS += $(call qstrip,$(BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS))
# 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.
.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
TOOLCHAIN_EXTERNAL_PREFIX = $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PREFIX))
toolchain-external: fix potential entire root filesystem removal This reverts commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 and reworks the code to fix a major and potentially catastrophic bug when the following conditions are met: - The user has selected a "known toolchain profile", such as a Linaro toolchain, a Sourcery CodeBench toolchain etc. People using "custom toolchain profile" are not affected. - The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to indicate that the toolchain is already locally available (as opposed to having Buildroot download and extract the toolchain) - The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his toolchain is directly available through the PATH environment variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot will do something silly (remove the toolchain contents), but that are limited to the toolchain itself. When such conditions are met, Buildroot will run "rm -rf /*" due to TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty. This bug does not exist in 2016.05, and appeared in 2016.08 due to commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79. Commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 removed the assignment of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as part of a global cleanup to remove such assignments that supposedly had become unneeded following a fix of the package infrastructure (75630eba22b20d6140a5b58a6d1e35598fb3c0d3: core: do not attempt downloads with no _VERSION set). However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the following consequences: - Buildroot downloads the toolchain tarball (while we're saying the toolchain is already available). Not dramatic, but clearly buggy. - Buildroot registers a post-extract hook that moves the toolchain from its extract directory (output/build/toolchain-external-.../ to its final location in host/opt/ext-toolchain/). Before doing this, it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which should normally be host/opt/ext-toolchain/). Another mistake that caused the bug is commit b731dc7bfb9c8ce7be502711f0b44ccab5515f1d ("toolchain-external: make extraction idempotent"), which introduce the dangerous call "rm -rf $(var)/*", which can be catastrophic if by mistake $(var) is empty. Instead, this commit should have just used rm -rf $(var) to remove the directory instead: it would have failed without consequences if $(var) is empty, and the directory was anyway already re-created right after with a mkdir. To address this problem, we: - Revert commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79, so that _SOURCE and _SITE are empty in the pre-installed toolchain case. - Rework the code to ensure that similar problems will no happen in the future, by: - Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is only needed when Buildroot downloaded the toolchain. - Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which is the path in which Buildroot installs external toolchains when it is in charge of downloading/extracting them. Then, the TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which is guaranteed to be non-empty. - Replace the removal of the directory contents $(var)/* by removing the directory itself $(var). The directory was anyway already re-created if needed afterwards. Thanks to doing this, if $(var) ever becomes empty, we will do "rm -rf" which will fail and abort the build, and not the catastrophic "rm -rf /*". Reported-by: Mason <slash.tmp@free.fr> Cc: Mason <slash.tmp@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-15 10:58:28 +02:00
TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR = $(HOST_DIR)/opt/ext-toolchain
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD),y)
toolchain-external: fix potential entire root filesystem removal This reverts commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 and reworks the code to fix a major and potentially catastrophic bug when the following conditions are met: - The user has selected a "known toolchain profile", such as a Linaro toolchain, a Sourcery CodeBench toolchain etc. People using "custom toolchain profile" are not affected. - The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to indicate that the toolchain is already locally available (as opposed to having Buildroot download and extract the toolchain) - The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his toolchain is directly available through the PATH environment variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot will do something silly (remove the toolchain contents), but that are limited to the toolchain itself. When such conditions are met, Buildroot will run "rm -rf /*" due to TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty. This bug does not exist in 2016.05, and appeared in 2016.08 due to commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79. Commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 removed the assignment of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as part of a global cleanup to remove such assignments that supposedly had become unneeded following a fix of the package infrastructure (75630eba22b20d6140a5b58a6d1e35598fb3c0d3: core: do not attempt downloads with no _VERSION set). However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the following consequences: - Buildroot downloads the toolchain tarball (while we're saying the toolchain is already available). Not dramatic, but clearly buggy. - Buildroot registers a post-extract hook that moves the toolchain from its extract directory (output/build/toolchain-external-.../ to its final location in host/opt/ext-toolchain/). Before doing this, it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which should normally be host/opt/ext-toolchain/). Another mistake that caused the bug is commit b731dc7bfb9c8ce7be502711f0b44ccab5515f1d ("toolchain-external: make extraction idempotent"), which introduce the dangerous call "rm -rf $(var)/*", which can be catastrophic if by mistake $(var) is empty. Instead, this commit should have just used rm -rf $(var) to remove the directory instead: it would have failed without consequences if $(var) is empty, and the directory was anyway already re-created right after with a mkdir. To address this problem, we: - Revert commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79, so that _SOURCE and _SITE are empty in the pre-installed toolchain case. - Rework the code to ensure that similar problems will no happen in the future, by: - Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is only needed when Buildroot downloaded the toolchain. - Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which is the path in which Buildroot installs external toolchains when it is in charge of downloading/extracting them. Then, the TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which is guaranteed to be non-empty. - Replace the removal of the directory contents $(var)/* by removing the directory itself $(var). The directory was anyway already re-created if needed afterwards. Thanks to doing this, if $(var) ever becomes empty, we will do "rm -rf" which will fail and abort the build, and not the catastrophic "rm -rf /*". Reported-by: Mason <slash.tmp@free.fr> Cc: Mason <slash.tmp@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-15 10:58:28 +02:00
TOOLCHAIN_EXTERNAL_INSTALL_DIR = $(TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR)
else
.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
TOOLCHAIN_EXTERNAL_INSTALL_DIR = $(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 := $(shell dirname $(shell which $(TOOLCHAIN_EXTERNAL_PREFIX)-gcc))
endif
else
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX),y)
TOOLCHAIN_EXTERNAL_BIN := $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/$(TOOLCHAIN_EXTERNAL_PREFIX)/bin
else
TOOLCHAIN_EXTERNAL_BIN := $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/bin
endif
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_TOOLCHAIN_WRAPPER_ARGS += \
-DBR_CROSS_PATH_SUFFIX='"$(TOOLCHAIN_EXTERNAL_SUFFIX)"'
.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
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_FC = $(TOOLCHAIN_EXTERNAL_CROSS)gfortran$(TOOLCHAIN_EXTERNAL_SUFFIX)
TOOLCHAIN_EXTERNAL_READELF = $(TOOLCHAIN_EXTERNAL_CROSS)readelf$(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
ifeq ($(call qstrip,$(BR2_GCC_TARGET_CPU_REVISION)),)
.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
CC_TARGET_CPU_ := $(call qstrip,$(BR2_GCC_TARGET_CPU))
else
.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
CC_TARGET_CPU_ := $(call qstrip,$(BR2_GCC_TARGET_CPU)-$(BR2_GCC_TARGET_CPU_REVISION))
endif
.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
CC_TARGET_ARCH_ := $(call qstrip,$(BR2_GCC_TARGET_ARCH))
CC_TARGET_ABI_ := $(call qstrip,$(BR2_GCC_TARGET_ABI))
CC_TARGET_FPU_ := $(call qstrip,$(BR2_GCC_TARGET_FPU))
CC_TARGET_FLOAT_ABI_ := $(call qstrip,$(BR2_GCC_TARGET_FLOAT_ABI))
CC_TARGET_MODE_ := $(call qstrip,$(BR2_GCC_TARGET_MODE))
# 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 ($(CC_TARGET_ARCH_),)
TOOLCHAIN_EXTERNAL_CFLAGS += -march=$(CC_TARGET_ARCH_)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_ARCH='"$(CC_TARGET_ARCH_)"'
endif
ifneq ($(CC_TARGET_CPU_),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mcpu=$(CC_TARGET_CPU_)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_CPU='"$(CC_TARGET_CPU_)"'
endif
ifneq ($(CC_TARGET_ABI_),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mabi=$(CC_TARGET_ABI_)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_ABI='"$(CC_TARGET_ABI_)"'
endif
ifneq ($(CC_TARGET_FPU_),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mfpu=$(CC_TARGET_FPU_)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_FPU='"$(CC_TARGET_FPU_)"'
endif
ifneq ($(CC_TARGET_FLOAT_ABI_),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mfloat-abi=$(CC_TARGET_FLOAT_ABI_)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_FLOAT_ABI='"$(CC_TARGET_FLOAT_ABI_)"'
endif
ifneq ($(CC_TARGET_MODE_),)
TOOLCHAIN_EXTERNAL_CFLAGS += -m$(CC_TARGET_MODE_)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_MODE='"$(CC_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
# musl does not provide an implementation for sys/queue.h or sys/cdefs.h.
# So, add the musl-compat-headers package that will install those files,
# into the staging directory:
# sys/queue.h: header from NetBSD
# sys/cdefs.h: minimalist header bundled in Buildroot
ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
TOOLCHAIN_EXTERNAL_DEPENDENCIES += musl-compat-headers
endif
# The Codescape toolchain uses a sysroot layout that places them
# side-by-side instead of nested like multilibs. A symlink is needed
# much like for the nested sysroots which are handled in
# copy_toolchain_sysroot but there is not enough information in there
# to determine whether the sysroot layout was nested or side-by-side.
# Add the symlink here for now.
define TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_SYMLINK
$(Q)ARCH_SYSROOT_DIR="$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))"; \
ARCH_SUBDIR=`basename $${ARCH_SYSROOT_DIR}`; \
ln -snf . $(STAGING_DIR)/$${ARCH_SUBDIR}
endef
# Special fixup for Codescape MIPS toolchains, that have bin-<abi> and
# sbin-<abi> directories. We create symlinks bin -> bin-<abi> and sbin
# -> sbin-<abi> so that the rest of Buildroot can find the toolchain
# tools in the appropriate location.
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESCAPE_IMG_MIPS)$(BR2_TOOLCHAIN_EXTERNAL_CODESCAPE_MTI_MIPS),y)
ifeq ($(BR2_MIPS_OABI32),y)
TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_BIN_DIR_SUFFIX = o32
else ifeq ($(BR2_MIPS_NABI32),y)
TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_BIN_DIR_SUFFIX = n32
else ifeq ($(BR2_MIPS_NABI64),y)
TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_BIN_DIR_SUFFIX = n64
endif
define TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_STAGING_FIXUPS
rmdir $(STAGING_DIR)/usr/bin $(STAGING_DIR)/usr/sbin
ln -sf bin-$(TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_BIN_DIR_SUFFIX) $(STAGING_DIR)/usr/bin
ln -sf sbin-$(TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_BIN_DIR_SUFFIX) $(STAGING_DIR)/usr/sbin
endef
endif
# Special handling for Blackfin toolchain, because of the split in two
# tarballs, and the organization of tarball contents. The tarballs
# contain ./opt/uClinux/{bfin-uclinux,bfin-linux-uclibc} directories,
# which themselves contain the toolchain. This is why we strip more
# components than usual.
define TOOLCHAIN_EXTERNAL_BLACKFIN_UCLIBC_EXTRA_EXTRACT
$(call suitable-extractor,$(TOOLCHAIN_EXTERNAL_EXTRA_DOWNLOADS)) $(DL_DIR)/$(TOOLCHAIN_EXTERNAL_EXTRA_DOWNLOADS) | \
$(TAR) --strip-components=3 --hard-dereference -C $(@D) $(TAR_OPTIONS) -
endef
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM),y)
TOOLCHAIN_EXTERNAL_SITE = http://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi
TOOLCHAIN_EXTERNAL_SOURCE = arm-2014.05-29-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_ARAGO_ARMV7A),y)
TOOLCHAIN_EXTERNAL_SITE = http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/exports
TOOLCHAIN_EXTERNAL_SOURCE = arago-2011.09-armv7a-linux-gnueabi-sdk.tar.bz2
TOOLCHAIN_EXTERNAL_ACTUAL_SOURCE_TARBALL = arago-toolchain-2011.09-sources.tar.bz2
define TOOLCHAIN_EXTERNAL_FIXUP_CMDS
toolchain/external: use generic extract commands (!blackfin case) Now that packages can provide a list of files to be excluded when extracting their archive, downloaded external toolchains are no longer special in this respect. Still, those toolchains are currently extracted directly into their final location, $(HOST_DIR)/opt/ext-toolchain/ which means we still need a custom extract command. Except, we don't really need it: we can just move the toolchain, after it's been extracted by the generic extract command, with a post-extract hook. This means that: - we now extract the toolchain with the generic extract command, - the toolchain is thus extracted into $(@D) , - fixup commands are run against $(@D), as a post-extract hook, instead of against $(HOST_DIR)/opt/ext-toolchain , - once this is done, we move $(@D)/* into the final location with a new post-extract hook. Note: the blackfin case is special, and will be handled in a follow-up patch. [Thomas: register the TOOLCHAIN_EXTERNAL_FIXUP_CMDS only for the Arago case, add some additional comments in the code about why we're moving the toolchain around.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-24 14:48:56 +02:00
mv $(@D)/arago-2011.09/armv7a/* $(@D)/
rm -rf $(@D)/arago-2011.09/
endef
toolchain/external: use generic extract commands (!blackfin case) Now that packages can provide a list of files to be excluded when extracting their archive, downloaded external toolchains are no longer special in this respect. Still, those toolchains are currently extracted directly into their final location, $(HOST_DIR)/opt/ext-toolchain/ which means we still need a custom extract command. Except, we don't really need it: we can just move the toolchain, after it's been extracted by the generic extract command, with a post-extract hook. This means that: - we now extract the toolchain with the generic extract command, - the toolchain is thus extracted into $(@D) , - fixup commands are run against $(@D), as a post-extract hook, instead of against $(HOST_DIR)/opt/ext-toolchain , - once this is done, we move $(@D)/* into the final location with a new post-extract hook. Note: the blackfin case is special, and will be handled in a follow-up patch. [Thomas: register the TOOLCHAIN_EXTERNAL_FIXUP_CMDS only for the Arago case, add some additional comments in the code about why we're moving the toolchain around.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-24 14:48:56 +02:00
TOOLCHAIN_EXTERNAL_POST_EXTRACT_HOOKS += TOOLCHAIN_EXTERNAL_FIXUP_CMDS
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_ARAGO_ARMV5TE),y)
TOOLCHAIN_EXTERNAL_SITE = http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/exports
TOOLCHAIN_EXTERNAL_SOURCE = arago-2011.09-armv5te-linux-gnueabi-sdk.tar.bz2
TOOLCHAIN_EXTERNAL_ACTUAL_SOURCE_TARBALL = arago-toolchain-2011.09-sources.tar.bz2
define TOOLCHAIN_EXTERNAL_FIXUP_CMDS
toolchain/external: use generic extract commands (!blackfin case) Now that packages can provide a list of files to be excluded when extracting their archive, downloaded external toolchains are no longer special in this respect. Still, those toolchains are currently extracted directly into their final location, $(HOST_DIR)/opt/ext-toolchain/ which means we still need a custom extract command. Except, we don't really need it: we can just move the toolchain, after it's been extracted by the generic extract command, with a post-extract hook. This means that: - we now extract the toolchain with the generic extract command, - the toolchain is thus extracted into $(@D) , - fixup commands are run against $(@D), as a post-extract hook, instead of against $(HOST_DIR)/opt/ext-toolchain , - once this is done, we move $(@D)/* into the final location with a new post-extract hook. Note: the blackfin case is special, and will be handled in a follow-up patch. [Thomas: register the TOOLCHAIN_EXTERNAL_FIXUP_CMDS only for the Arago case, add some additional comments in the code about why we're moving the toolchain around.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-24 14:48:56 +02:00
mv $(@D)/arago-2011.09/armv5te/* $(@D)/
rm -rf $(@D)/arago-2011.09/
endef
toolchain/external: use generic extract commands (!blackfin case) Now that packages can provide a list of files to be excluded when extracting their archive, downloaded external toolchains are no longer special in this respect. Still, those toolchains are currently extracted directly into their final location, $(HOST_DIR)/opt/ext-toolchain/ which means we still need a custom extract command. Except, we don't really need it: we can just move the toolchain, after it's been extracted by the generic extract command, with a post-extract hook. This means that: - we now extract the toolchain with the generic extract command, - the toolchain is thus extracted into $(@D) , - fixup commands are run against $(@D), as a post-extract hook, instead of against $(HOST_DIR)/opt/ext-toolchain , - once this is done, we move $(@D)/* into the final location with a new post-extract hook. Note: the blackfin case is special, and will be handled in a follow-up patch. [Thomas: register the TOOLCHAIN_EXTERNAL_FIXUP_CMDS only for the Arago case, add some additional comments in the code about why we're moving the toolchain around.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-24 14:48:56 +02:00
TOOLCHAIN_EXTERNAL_POST_EXTRACT_HOOKS += TOOLCHAIN_EXTERNAL_FIXUP_CMDS
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM),y)
TOOLCHAIN_EXTERNAL_SITE = https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/arm-linux-gnueabihf
ifeq ($(HOSTARCH),x86)
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-i686_arm-linux-gnueabihf.tar.xz
else
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf.tar.xz
endif
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_ARMEB),y)
TOOLCHAIN_EXTERNAL_SITE = https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/armeb-linux-gnueabihf
ifeq ($(HOSTARCH),x86)
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-i686_armeb-linux-gnueabihf.tar.xz
else
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-x86_64_armeb-linux-gnueabihf.tar.xz
endif
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS),y)
TOOLCHAIN_EXTERNAL_SITE = http://sourcery.mentor.com/public/gnu_toolchain/mips-linux-gnu
TOOLCHAIN_EXTERNAL_SOURCE = mips-2016.05-8-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII),y)
TOOLCHAIN_EXTERNAL_SITE = http://sourcery.mentor.com/public/gnu_toolchain/nios2-linux-gnu
TOOLCHAIN_EXTERNAL_SOURCE = sourceryg++-2016.05-10-nios2-linux-gnu-i686-pc-linux-gnu.tar.bz2
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_SH),y)
TOOLCHAIN_EXTERNAL_SITE = https://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu
TOOLCHAIN_EXTERNAL_SOURCE = renesas-2012.09-61-sh-linux-gnu-i686-pc-linux-gnu.tar.bz2
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_X86),y)
TOOLCHAIN_EXTERNAL_SITE = https://sourcery.mentor.com/public/gnu_toolchain/i686-pc-linux-gnu
TOOLCHAIN_EXTERNAL_SOURCE = ia32-2012.09-62-i686-pc-linux-gnu-i386-linux.tar.bz2
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_AMD64),y)
TOOLCHAIN_EXTERNAL_SITE = https://sourcery.mentor.com/public/gnu_toolchain/x86_64-amd-linux-gnu
TOOLCHAIN_EXTERNAL_SOURCE = amd-2015.11-139-x86_64-amd-linux-gnu-i686-pc-linux-gnu.tar.bz2
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESCAPE_IMG_MIPS),y)
TOOLCHAIN_EXTERNAL_SITE = http://codescape-mips-sdk.imgtec.com/components/toolchain/2016.05-03
TOOLCHAIN_EXTERNAL_SOURCE = Codescape.GNU.Tools.Package.2016.05-03.for.MIPS.IMG.Linux.CentOS-5.x86.tar.gz
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_SYMLINK
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_STAGING_FIXUPS
TOOLCHAIN_EXTERNAL_STRIP_COMPONENTS = 2
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESCAPE_MTI_MIPS),y)
TOOLCHAIN_EXTERNAL_SITE = http://codescape-mips-sdk.imgtec.com/components/toolchain/2016.05-03
TOOLCHAIN_EXTERNAL_SOURCE = Codescape.GNU.Tools.Package.2016.05-03.for.MIPS.MTI.Linux.CentOS-5.x86.tar.gz
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_SYMLINK
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_STAGING_FIXUPS
TOOLCHAIN_EXTERNAL_STRIP_COMPONENTS = 2
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX),y)
TOOLCHAIN_EXTERNAL_SITE = http://downloads.sourceforge.net/project/adi-toolchain/2014R1/2014R1-RC2/i386
TOOLCHAIN_EXTERNAL_SOURCE = blackfin-toolchain-2014R1-RC2.i386.tar.bz2
TOOLCHAIN_EXTERNAL_EXTRA_DOWNLOADS = blackfin-toolchain-uclibc-full-2014R1-RC2.i386.tar.bz2
TOOLCHAIN_EXTERNAL_STRIP_COMPONENTS = 3
TOOLCHAIN_EXTERNAL_POST_EXTRACT_HOOKS += TOOLCHAIN_EXTERNAL_BLACKFIN_UCLIBC_EXTRA_EXTRACT
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64),y)
TOOLCHAIN_EXTERNAL_SITE = https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/aarch64-linux-gnu
ifeq ($(HOSTARCH),x86)
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-i686_aarch64-linux-gnu.tar.xz
else
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu.tar.xz
endif
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64),y)
TOOLCHAIN_EXTERNAL_SITE = http://sourcery.mentor.com/public/gnu_toolchain/aarch64-amd-linux-gnu
TOOLCHAIN_EXTERNAL_SOURCE = aarch64-amd-2014.11-95-aarch64-amd-linux-gnu-i686-pc-linux-gnu.tar.bz2
define TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64_STAGING_FIXUP
ln -sf ld-2.20.so $(STAGING_DIR)/lib/ld-linux-aarch64.so.1
endef
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64_STAGING_FIXUP
define TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64_TARGET_FIXUP
ln -sf ld-2.20.so $(TARGET_DIR)/lib/ld-linux-aarch64.so.1
endef
TOOLCHAIN_EXTERNAL_POST_INSTALL_TARGET_HOOKS += TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64_TARGET_FIXUP
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_MUSL_CROSS),y)
TOOLCHAIN_EXTERNAL_VERSION = 1.1.12
TOOLCHAIN_EXTERNAL_SITE = https://googledrive.com/host/0BwnS5DMB0YQ6bDhPZkpOYVFhbk0/musl-$(TOOLCHAIN_EXTERNAL_VERSION)
ifeq ($(BR2_arm)$(BR2_ARM_EABI),yy)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-arm-linux-musleabi-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_arm)$(BR2_ARM_EABIHF),yy)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-arm-linux-musleabihf-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_armeb),y)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-armeb-linux-musleabi-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_i386),y)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-i486-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_mips),y)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-mips-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_mipsel):$(BR2_SOFT_FLOAT),y:)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-mipsel-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_mipsel):$(BR2_SOFT_FLOAT),y:y)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-mipsel-sf-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_powerpc),y)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-powerpc-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_sh4),y)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-sh4-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_sh4eb),y)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-sh4eb-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
else ifeq ($(BR2_x86_64),y)
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-x86_64-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
endif
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_SYNOPSYS_ARC),y)
TOOLCHAIN_EXTERNAL_SITE = https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2014.12
ifeq ($(BR2_arc750d)$(BR2_arc770d),y)
TOOLCHAIN_EXTERNAL_SYNOPSYS_CORE = arc700
else
TOOLCHAIN_EXTERNAL_SYNOPSYS_CORE = archs
endif
ifeq ($(BR2_arcle),y)
TOOLCHAIN_EXTERNAL_SYNOPSYS_ENDIANESS = le
else
TOOLCHAIN_EXTERNAL_SYNOPSYS_ENDIANESS = be
endif
TOOLCHAIN_EXTERNAL_SOURCE = arc_gnu_2014.12_prebuilt_uclibc_$(TOOLCHAIN_EXTERNAL_SYNOPSYS_ENDIANESS)_$(TOOLCHAIN_EXTERNAL_SYNOPSYS_CORE)_linux_install.tar.gz
else
# Custom toolchain
TOOLCHAIN_EXTERNAL_SITE = $(patsubst %/,%,$(dir $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_URL))))
TOOLCHAIN_EXTERNAL_SOURCE = $(notdir $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_URL)))
# We can't check hashes for custom downloaded toolchains
BR_NO_CHECK_HASH_FOR += $(TOOLCHAIN_EXTERNAL_SOURCE)
endif
external-toolchain: Support for multilib toolchains Multilib toolchains provide different versions of the base libraries for different architecture variants. For example, the ARM Codesourcery toolchain provides base libraries for ARMv5 (default), ARMv4t and Thumb2. Depending on the -march= argument passed to gcc, the sysroot used by the compiler is therefore different. This means that the sysroot location in CROSS-gcc -v cannot be used. Instead, we must use CROSS-gcc -print-sysroot when available and fall back to the old way if unavailable. Moreover, we cannot simply copy the full sysroot as we used to do, because the sysroot organization of multilib toolchain is more complicated. In Codesourcery toolchains, we have : / etc -- for ARMv5 lib -- for ARMv5 sbin -- for ARMv5 usr -- for ARMv5 (includes headers) armv4t etc -- for ARMv4t lib -- for ARMv4t sbin -- for ARMv4t usr -- for ARMv4t (no headers!) thumb2 etc -- for Thumb2 lib -- for Thumb2 sbin -- for Thumb2 usr -- for Thumb2 (no headers!) So we have the default ARMv5 architecture variant that is installed in the main directory, and we have subdirectories for the ARMv4t and Thumb2 architecture variants. Copying the full sysroot to the staging directory doesn't work. All our packages are based on the fact that they should install libraries in staging/usr/lib. But if ARMv4t is used, the compiler would only look in staging/armv4t/usr/lib for libraries (even when overriding the sysroot with the --sysroot option, the multilib compiler suffixes the sysroot directory with the architecture variant if it matches a recognized one). Therefore, we have to copy only the sysroot that we are interested in. This is rendered a little bit complicated by the fact that the armv4t and thumb2 sysroot do not contain the headers since they are shared with the armv5 sysroot. So, this patch : * Modifies how we compute SYSROOT_DIR in order to use -print-sysroot if it exists. SYSROOT_DIR contains the location of the main sysroot directory, i.e the sysroot for the default architecture variant. * Defines ARCH_SUBDIR as the subdirectory in the main sysroot for the currently selected architecture variant (in our case, it can be ".", "armv4t" or "thumb2"). ARCH_SYSROOT_DIR is defined as the full path to the sysroot of the currently selected architecture variant. * Modifies copy_toolchain_lib_root (which copies a library to the target/ directory) so that libraries are taken from ARCH_SYSROOT_DIR instead of SYSROOT_DIR. This ensures that libraries for the correct architecture variant are properly copied to the target. * Modifies copy_toolchain_sysroot (which copies the sysroot to the staging/ directory), so that it copies the contents of ARCH_SYSROOT_DIR, and if needed, adds the headers from the main sysroot directory and a symbolic link (armv4t -> . or thumb2 -> .) to make the compiler believe that its sysroot is really in armv4t/ or thumb2/. Tested with Codesourcery 2009q1 ARM toolchain, Crosstool-NG ARM glibc and ARM uClibc toolchains. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2009-08-22 01:13:22 +02:00
# Some toolchain vendors have a regular file naming pattern.
# For them, mass-define _ACTUAL_SOURCE_TARBALL based _SITE.
ifneq ($(findstring sourcery.mentor.com/public/gnu_toolchain,$(TOOLCHAIN_EXTERNAL_SITE)),)
TOOLCHAIN_EXTERNAL_ACTUAL_SOURCE_TARBALL ?= \
$(subst -i686-pc-linux-gnu.tar.bz2,.src.tar.bz2,$(subst -i686-pc-linux-gnu-i386-linux.tar.bz2,-i686-pc-linux-gnu.src.tar.bz2,$(TOOLCHAIN_EXTERNAL_SOURCE)))
endif
toolchain-external: fix potential entire root filesystem removal This reverts commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 and reworks the code to fix a major and potentially catastrophic bug when the following conditions are met: - The user has selected a "known toolchain profile", such as a Linaro toolchain, a Sourcery CodeBench toolchain etc. People using "custom toolchain profile" are not affected. - The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to indicate that the toolchain is already locally available (as opposed to having Buildroot download and extract the toolchain) - The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his toolchain is directly available through the PATH environment variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot will do something silly (remove the toolchain contents), but that are limited to the toolchain itself. When such conditions are met, Buildroot will run "rm -rf /*" due to TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty. This bug does not exist in 2016.05, and appeared in 2016.08 due to commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79. Commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 removed the assignment of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as part of a global cleanup to remove such assignments that supposedly had become unneeded following a fix of the package infrastructure (75630eba22b20d6140a5b58a6d1e35598fb3c0d3: core: do not attempt downloads with no _VERSION set). However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the following consequences: - Buildroot downloads the toolchain tarball (while we're saying the toolchain is already available). Not dramatic, but clearly buggy. - Buildroot registers a post-extract hook that moves the toolchain from its extract directory (output/build/toolchain-external-.../ to its final location in host/opt/ext-toolchain/). Before doing this, it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which should normally be host/opt/ext-toolchain/). Another mistake that caused the bug is commit b731dc7bfb9c8ce7be502711f0b44ccab5515f1d ("toolchain-external: make extraction idempotent"), which introduce the dangerous call "rm -rf $(var)/*", which can be catastrophic if by mistake $(var) is empty. Instead, this commit should have just used rm -rf $(var) to remove the directory instead: it would have failed without consequences if $(var) is empty, and the directory was anyway already re-created right after with a mkdir. To address this problem, we: - Revert commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79, so that _SOURCE and _SITE are empty in the pre-installed toolchain case. - Rework the code to ensure that similar problems will no happen in the future, by: - Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is only needed when Buildroot downloaded the toolchain. - Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which is the path in which Buildroot installs external toolchains when it is in charge of downloading/extracting them. Then, the TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which is guaranteed to be non-empty. - Replace the removal of the directory contents $(var)/* by removing the directory itself $(var). The directory was anyway already re-created if needed afterwards. Thanks to doing this, if $(var) ever becomes empty, we will do "rm -rf" which will fail and abort the build, and not the catastrophic "rm -rf /*". Reported-by: Mason <slash.tmp@free.fr> Cc: Mason <slash.tmp@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-15 10:58:28 +02:00
# 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)
TOOLCHAIN_EXTERNAL_SITE =
TOOLCHAIN_EXTERNAL_SOURCE =
endif
TOOLCHAIN_EXTERNAL_ADD_TOOLCHAIN_DEPENDENCY = NO
TOOLCHAIN_EXTERNAL_INSTALL_STAGING = YES
# Normal handling of downloaded toolchain tarball extraction.
toolchain-external: fix potential entire root filesystem removal This reverts commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 and reworks the code to fix a major and potentially catastrophic bug when the following conditions are met: - The user has selected a "known toolchain profile", such as a Linaro toolchain, a Sourcery CodeBench toolchain etc. People using "custom toolchain profile" are not affected. - The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to indicate that the toolchain is already locally available (as opposed to having Buildroot download and extract the toolchain) - The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his toolchain is directly available through the PATH environment variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot will do something silly (remove the toolchain contents), but that are limited to the toolchain itself. When such conditions are met, Buildroot will run "rm -rf /*" due to TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty. This bug does not exist in 2016.05, and appeared in 2016.08 due to commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79. Commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 removed the assignment of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as part of a global cleanup to remove such assignments that supposedly had become unneeded following a fix of the package infrastructure (75630eba22b20d6140a5b58a6d1e35598fb3c0d3: core: do not attempt downloads with no _VERSION set). However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the following consequences: - Buildroot downloads the toolchain tarball (while we're saying the toolchain is already available). Not dramatic, but clearly buggy. - Buildroot registers a post-extract hook that moves the toolchain from its extract directory (output/build/toolchain-external-.../ to its final location in host/opt/ext-toolchain/). Before doing this, it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which should normally be host/opt/ext-toolchain/). Another mistake that caused the bug is commit b731dc7bfb9c8ce7be502711f0b44ccab5515f1d ("toolchain-external: make extraction idempotent"), which introduce the dangerous call "rm -rf $(var)/*", which can be catastrophic if by mistake $(var) is empty. Instead, this commit should have just used rm -rf $(var) to remove the directory instead: it would have failed without consequences if $(var) is empty, and the directory was anyway already re-created right after with a mkdir. To address this problem, we: - Revert commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79, so that _SOURCE and _SITE are empty in the pre-installed toolchain case. - Rework the code to ensure that similar problems will no happen in the future, by: - Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is only needed when Buildroot downloaded the toolchain. - Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which is the path in which Buildroot installs external toolchains when it is in charge of downloading/extracting them. Then, the TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which is guaranteed to be non-empty. - Replace the removal of the directory contents $(var)/* by removing the directory itself $(var). The directory was anyway already re-created if needed afterwards. Thanks to doing this, if $(var) ever becomes empty, we will do "rm -rf" which will fail and abort the build, and not the catastrophic "rm -rf /*". Reported-by: Mason <slash.tmp@free.fr> Cc: Mason <slash.tmp@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-15 10:58:28 +02:00
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD),y)
toolchain/external: use generic extract commands (!blackfin case) Now that packages can provide a list of files to be excluded when extracting their archive, downloaded external toolchains are no longer special in this respect. Still, those toolchains are currently extracted directly into their final location, $(HOST_DIR)/opt/ext-toolchain/ which means we still need a custom extract command. Except, we don't really need it: we can just move the toolchain, after it's been extracted by the generic extract command, with a post-extract hook. This means that: - we now extract the toolchain with the generic extract command, - the toolchain is thus extracted into $(@D) , - fixup commands are run against $(@D), as a post-extract hook, instead of against $(HOST_DIR)/opt/ext-toolchain , - once this is done, we move $(@D)/* into the final location with a new post-extract hook. Note: the blackfin case is special, and will be handled in a follow-up patch. [Thomas: register the TOOLCHAIN_EXTERNAL_FIXUP_CMDS only for the Arago case, add some additional comments in the code about why we're moving the toolchain around.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-24 14:48:56 +02:00
TOOLCHAIN_EXTERNAL_EXCLUDES = usr/lib/locale/*
# 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
toolchain-external: fix potential entire root filesystem removal This reverts commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 and reworks the code to fix a major and potentially catastrophic bug when the following conditions are met: - The user has selected a "known toolchain profile", such as a Linaro toolchain, a Sourcery CodeBench toolchain etc. People using "custom toolchain profile" are not affected. - The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to indicate that the toolchain is already locally available (as opposed to having Buildroot download and extract the toolchain) - The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his toolchain is directly available through the PATH environment variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot will do something silly (remove the toolchain contents), but that are limited to the toolchain itself. When such conditions are met, Buildroot will run "rm -rf /*" due to TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty. This bug does not exist in 2016.05, and appeared in 2016.08 due to commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79. Commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 removed the assignment of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as part of a global cleanup to remove such assignments that supposedly had become unneeded following a fix of the package infrastructure (75630eba22b20d6140a5b58a6d1e35598fb3c0d3: core: do not attempt downloads with no _VERSION set). However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the following consequences: - Buildroot downloads the toolchain tarball (while we're saying the toolchain is already available). Not dramatic, but clearly buggy. - Buildroot registers a post-extract hook that moves the toolchain from its extract directory (output/build/toolchain-external-.../ to its final location in host/opt/ext-toolchain/). Before doing this, it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which should normally be host/opt/ext-toolchain/). Another mistake that caused the bug is commit b731dc7bfb9c8ce7be502711f0b44ccab5515f1d ("toolchain-external: make extraction idempotent"), which introduce the dangerous call "rm -rf $(var)/*", which can be catastrophic if by mistake $(var) is empty. Instead, this commit should have just used rm -rf $(var) to remove the directory instead: it would have failed without consequences if $(var) is empty, and the directory was anyway already re-created right after with a mkdir. To address this problem, we: - Revert commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79, so that _SOURCE and _SITE are empty in the pre-installed toolchain case. - Rework the code to ensure that similar problems will no happen in the future, by: - Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is only needed when Buildroot downloaded the toolchain. - Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which is the path in which Buildroot installs external toolchains when it is in charge of downloading/extracting them. Then, the TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which is guaranteed to be non-empty. - Replace the removal of the directory contents $(var)/* by removing the directory itself $(var). The directory was anyway already re-created if needed afterwards. Thanks to doing this, if $(var) ever becomes empty, we will do "rm -rf" which will fail and abort the build, and not the catastrophic "rm -rf /*". Reported-by: Mason <slash.tmp@free.fr> Cc: Mason <slash.tmp@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-15 10:58:28 +02:00
# into TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR.
toolchain/external: use generic extract commands (!blackfin case) Now that packages can provide a list of files to be excluded when extracting their archive, downloaded external toolchains are no longer special in this respect. Still, those toolchains are currently extracted directly into their final location, $(HOST_DIR)/opt/ext-toolchain/ which means we still need a custom extract command. Except, we don't really need it: we can just move the toolchain, after it's been extracted by the generic extract command, with a post-extract hook. This means that: - we now extract the toolchain with the generic extract command, - the toolchain is thus extracted into $(@D) , - fixup commands are run against $(@D), as a post-extract hook, instead of against $(HOST_DIR)/opt/ext-toolchain , - once this is done, we move $(@D)/* into the final location with a new post-extract hook. Note: the blackfin case is special, and will be handled in a follow-up patch. [Thomas: register the TOOLCHAIN_EXTERNAL_FIXUP_CMDS only for the Arago case, add some additional comments in the code about why we're moving the toolchain around.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-24 14:48:56 +02:00
define TOOLCHAIN_EXTERNAL_MOVE
toolchain-external: fix potential entire root filesystem removal This reverts commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 and reworks the code to fix a major and potentially catastrophic bug when the following conditions are met: - The user has selected a "known toolchain profile", such as a Linaro toolchain, a Sourcery CodeBench toolchain etc. People using "custom toolchain profile" are not affected. - The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to indicate that the toolchain is already locally available (as opposed to having Buildroot download and extract the toolchain) - The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his toolchain is directly available through the PATH environment variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot will do something silly (remove the toolchain contents), but that are limited to the toolchain itself. When such conditions are met, Buildroot will run "rm -rf /*" due to TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty. This bug does not exist in 2016.05, and appeared in 2016.08 due to commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79. Commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79 removed the assignment of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as part of a global cleanup to remove such assignments that supposedly had become unneeded following a fix of the package infrastructure (75630eba22b20d6140a5b58a6d1e35598fb3c0d3: core: do not attempt downloads with no _VERSION set). However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the following consequences: - Buildroot downloads the toolchain tarball (while we're saying the toolchain is already available). Not dramatic, but clearly buggy. - Buildroot registers a post-extract hook that moves the toolchain from its extract directory (output/build/toolchain-external-.../ to its final location in host/opt/ext-toolchain/). Before doing this, it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which should normally be host/opt/ext-toolchain/). Another mistake that caused the bug is commit b731dc7bfb9c8ce7be502711f0b44ccab5515f1d ("toolchain-external: make extraction idempotent"), which introduce the dangerous call "rm -rf $(var)/*", which can be catastrophic if by mistake $(var) is empty. Instead, this commit should have just used rm -rf $(var) to remove the directory instead: it would have failed without consequences if $(var) is empty, and the directory was anyway already re-created right after with a mkdir. To address this problem, we: - Revert commit a0aa7e0e1750f6ace2879ea8adb1425a41431b79, so that _SOURCE and _SITE are empty in the pre-installed toolchain case. - Rework the code to ensure that similar problems will no happen in the future, by: - Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is only needed when Buildroot downloaded the toolchain. - Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which is the path in which Buildroot installs external toolchains when it is in charge of downloading/extracting them. Then, the TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which is guaranteed to be non-empty. - Replace the removal of the directory contents $(var)/* by removing the directory itself $(var). The directory was anyway already re-created if needed afterwards. Thanks to doing this, if $(var) ever becomes empty, we will do "rm -rf" which will fail and abort the build, and not the catastrophic "rm -rf /*". Reported-by: Mason <slash.tmp@free.fr> Cc: Mason <slash.tmp@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-15 10:58:28 +02:00
rm -rf $(TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR)
mkdir -p $(TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR)
mv $(@D)/* $(TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR)/
endef
toolchain/external: use generic extract commands (!blackfin case) Now that packages can provide a list of files to be excluded when extracting their archive, downloaded external toolchains are no longer special in this respect. Still, those toolchains are currently extracted directly into their final location, $(HOST_DIR)/opt/ext-toolchain/ which means we still need a custom extract command. Except, we don't really need it: we can just move the toolchain, after it's been extracted by the generic extract command, with a post-extract hook. This means that: - we now extract the toolchain with the generic extract command, - the toolchain is thus extracted into $(@D) , - fixup commands are run against $(@D), as a post-extract hook, instead of against $(HOST_DIR)/opt/ext-toolchain , - once this is done, we move $(@D)/* into the final location with a new post-extract hook. Note: the blackfin case is special, and will be handled in a follow-up patch. [Thomas: register the TOOLCHAIN_EXTERNAL_FIXUP_CMDS only for the Arago case, add some additional comments in the code about why we're moving the toolchain around.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-24 14:48:56 +02:00
TOOLCHAIN_EXTERNAL_POST_EXTRACT_HOOKS += \
TOOLCHAIN_EXTERNAL_MOVE
endif
# 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
# 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
$$(printf $(call toolchain_find_libc_a,$(1)) | sed -r -e 's:.*/(usr/)?(lib(32|64)?([^/]*)?)/([^/]*/)?libc.a:\2:')
endef
# 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 TOOLCHAIN_EXTERNAL_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,\
$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC)),\
$(call qstrip,$(BR2_TOOLCHAIN_HEADERS_AT_LEAST))); \
$(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_READELF)) ; \
fi ; \
if test "$(BR2_INSTALL_LIBSTDCPP)" = "y" ; then \
$(call check_cplusplus,$(TOOLCHAIN_EXTERNAL_CXX)) ; \
fi ; \
if test "$(BR2_TOOLCHAIN_HAS_FORTRAN)" = "y" ; then \
$(call check_fortran,$(TOOLCHAIN_EXTERNAL_FC)) ; \
fi ; \
if test "$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC)" = "y" ; then \
$(call check_uclibc,$${SYSROOT_DIR}) ; \
elif test "$(BR2_TOOLCHAIN_EXTERNAL_MUSL)" = "y" ; then \
$(call check_musl,$${SYSROOT_DIR}) ; \
else \
$(call check_glibc,$${SYSROOT_DIR}) ; \
fi
$(Q)$(call check_toolchain_ssp,$(TOOLCHAIN_EXTERNAL_CC))
endef
# With the musl C library, the libc.so library directly plays the role
# of the dynamic library loader. We just need to create a symbolic
# link to libc.so with the appropriate name.
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_MUSL),y)
ifeq ($(BR2_i386),y)
MUSL_ARCH = i386
else ifeq ($(BR2_ARM_EABIHF),y)
MUSL_ARCH = armhf
else ifeq ($(BR2_mipsel):$(BR2_SOFT_FLOAT),y:y)
MUSL_ARCH = mipsel-sf
else ifeq ($(BR2_sh),y)
MUSL_ARCH = sh
else
MUSL_ARCH = $(ARCH)
endif
define TOOLCHAIN_EXTERNAL_MUSL_LD_LINK
ln -sf libc.so $(TARGET_DIR)/lib/ld-musl-$(MUSL_ARCH).so.1
endef
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_MUSL_LD_LINK
endif
toolchain-external: create symlink ARCH_LIB_DIR->lib Currently, following symbolic links are created in both target and staging directories: - lib(32|64) --> lib - usr/lib(32|64) --> lib The decision for lib32 or lib64 is based on the target architecture configuration in buildroot (BR2_ARCH_IS_64). In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (ABI=n32; likewise for lib64-fp in case of ABI=n64) More generally the correct symbolic link is from (usr/)${ARCH_LIB_DIR}->lib. However, feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if ARCH_LIB_DIR is different. Hence, these links must be kept. Fix the problem as follows: - For internal toolchains: no change - For external toolchains: create a symlink ARCH_LIB_DIR->lib if (usr/)ARCH_LIB_DIR does not exist yet. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: "Yann E. Morin" <yann.morin.1998@free.fr> Cc: Romain Naour <romain.naour@gmail.com> Cc: Peter Korsgaard <peter@korsgaard.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Tested-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-01-28 13:32:46 +01:00
# 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 \
ln -snf lib "$${DESTDIR}/$${ARCH_LIB_DIR}" ; \
ln -snf 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
# 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).
Improve external toolchain logic to support IA32 Sourcery CodeBench toolchain The IA32 Sourcery CodeBench toolchain has a relatively special structure, with the following multilib variants: * Intel Pentium 4, 32 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Xeon Nocona, 64 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib64/ directory. * Intel Atom 32 bits, the multilib variant is in atom/ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Core 2 64 bits, the multilib variant is in core2/ relative to the main sysroot, with the libraries in lib64/ directory. So the first two variants are in the same sysroot, only the name of the directory for the libraries is different. Therefore, we introduce a new ARCH_LIB_DIR variable, which contains either 'lib' or 'lib64'. This variable is defined according to the location of the libc.a file for the selected multilib variant, and is then used when copying the libraries to the target and to the staging directory. In addition to this, we no longer use the -print-multi-directory to get the ARCH_SUBDIR, since in the case of the 64 bits variants of this toolchain, it returns just '64' and not a real path. Instead, we simply compute the difference between the arch-specific sysroot and the main sysroot. We also take that opportunity to expand the documentation on the meaning of the different variables. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2011-12-31 11:57:15 +01:00
#
# Variables are defined as follows:
#
# LIBC_A_LOCATION: location of the libc.a file in the default
# multilib variant (allows to find the main
# sysroot directory)
# Ex: /x-tools/mips-2011.03/mips-linux-gnu/libc/usr/lib/libc.a
#
# SYSROOT_DIR: the main sysroot directory, deduced from
# LIBC_A_LOCATION by removing the
# usr/lib[32|64]/libc.a part of the path.
Improve external toolchain logic to support IA32 Sourcery CodeBench toolchain The IA32 Sourcery CodeBench toolchain has a relatively special structure, with the following multilib variants: * Intel Pentium 4, 32 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Xeon Nocona, 64 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib64/ directory. * Intel Atom 32 bits, the multilib variant is in atom/ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Core 2 64 bits, the multilib variant is in core2/ relative to the main sysroot, with the libraries in lib64/ directory. So the first two variants are in the same sysroot, only the name of the directory for the libraries is different. Therefore, we introduce a new ARCH_LIB_DIR variable, which contains either 'lib' or 'lib64'. This variable is defined according to the location of the libc.a file for the selected multilib variant, and is then used when copying the libraries to the target and to the staging directory. In addition to this, we no longer use the -print-multi-directory to get the ARCH_SUBDIR, since in the case of the 64 bits variants of this toolchain, it returns just '64' and not a real path. Instead, we simply compute the difference between the arch-specific sysroot and the main sysroot. We also take that opportunity to expand the documentation on the meaning of the different variables. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2011-12-31 11:57:15 +01:00
# Ex: /x-tools/mips-2011.03/mips-linux-gnu/libc/
#
# ARCH_LIBC_A_LOCATION: location of the libc.a file in the selected
# multilib variant (taking into account the
# CFLAGS). Allows to find the sysroot of the
# selected multilib variant.
# Ex: /x-tools/mips-2011.03/mips-linux-gnu/libc/mips16/soft-float/el/usr/lib/libc.a
#
# ARCH_SYSROOT_DIR: the sysroot of the selected multilib variant,
# deduced from ARCH_LIBC_A_LOCATION by removing
# usr/lib[32|64]/libc.a at the end of the path.
Improve external toolchain logic to support IA32 Sourcery CodeBench toolchain The IA32 Sourcery CodeBench toolchain has a relatively special structure, with the following multilib variants: * Intel Pentium 4, 32 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Xeon Nocona, 64 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib64/ directory. * Intel Atom 32 bits, the multilib variant is in atom/ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Core 2 64 bits, the multilib variant is in core2/ relative to the main sysroot, with the libraries in lib64/ directory. So the first two variants are in the same sysroot, only the name of the directory for the libraries is different. Therefore, we introduce a new ARCH_LIB_DIR variable, which contains either 'lib' or 'lib64'. This variable is defined according to the location of the libc.a file for the selected multilib variant, and is then used when copying the libraries to the target and to the staging directory. In addition to this, we no longer use the -print-multi-directory to get the ARCH_SUBDIR, since in the case of the 64 bits variants of this toolchain, it returns just '64' and not a real path. Instead, we simply compute the difference between the arch-specific sysroot and the main sysroot. We also take that opportunity to expand the documentation on the meaning of the different variables. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2011-12-31 11:57:15 +01:00
# 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 ARCH_LIBC_A_LOCATION by
Improve external toolchain logic to support IA32 Sourcery CodeBench toolchain The IA32 Sourcery CodeBench toolchain has a relatively special structure, with the following multilib variants: * Intel Pentium 4, 32 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Xeon Nocona, 64 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib64/ directory. * Intel Atom 32 bits, the multilib variant is in atom/ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Core 2 64 bits, the multilib variant is in core2/ relative to the main sysroot, with the libraries in lib64/ directory. So the first two variants are in the same sysroot, only the name of the directory for the libraries is different. Therefore, we introduce a new ARCH_LIB_DIR variable, which contains either 'lib' or 'lib64'. This variable is defined according to the location of the libc.a file for the selected multilib variant, and is then used when copying the libraries to the target and to the staging directory. In addition to this, we no longer use the -print-multi-directory to get the ARCH_SUBDIR, since in the case of the 64 bits variants of this toolchain, it returns just '64' and not a real path. Instead, we simply compute the difference between the arch-specific sysroot and the main sysroot. We also take that opportunity to expand the documentation on the meaning of the different variables. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2011-12-31 11:57:15 +01:00
# 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.
toolchain-external: align library locations in target and staging dir The toolchain-external logic is roughly: - populate the staging dir by rsyncing the entire ${ARCH_LIB_DIR} and usr/${ARCH_LIB_DIR} from sysroot. - populate the target dir by explictly copying some libraries from sysroot into target/lib and some other libraries in target/usr/lib, the split being hardcoded into buildroot regardless of the location in the sysroot. This means that a library libfoo could be located in: staging/lib/libfoo.so target/usr/lib/libfoo.so When debugging an application that links against this library, gdb will fruitlessly search for 'usr/lib/libfoo.so' in staging, and then suggest to use 'set solib-search-path' which is a hack, really. To solve the problem, we need to make sure that libraries from the toolchain are installed in the same relative location in staging and target. Achieve this by: - replacing the convoluted search for libraries using for+find in sysroot with a simple find in staging. - determining DESTDIR for each library individually based on the location in staging. - treating LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS equivalently These changes also allow for the removal of most arguments to copy_toolchain_lib_root in the method itself and their callers. Test procedure: - set configuration for a given toolchain - make clean toolchain - find output/target | sort > /tmp/out-before - apply patch - make clean toolchain - find output/target | sort > /tmp/out-after - diff -u /tmp/out-before /tmp/out-after The only changes should be some libraries moving from lib to usr/lib or vice versa. Notable examples being libstdc++ and libatomic. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: - use -L instead of -follow in the find invocation, as suggested by Arnout. - move the BR2_STATIC_LIBS condition as a make condition rather than a shell condition, as suggested by Arnout.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-12 20:20:25 +01:00
#
# Please be very careful to check the major toolchain sources:
# Buildroot, Crosstool-NG, CodeSourcery and Linaro
# before doing any modification on the below logic.
Improve external toolchain logic to support IA32 Sourcery CodeBench toolchain The IA32 Sourcery CodeBench toolchain has a relatively special structure, with the following multilib variants: * Intel Pentium 4, 32 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Xeon Nocona, 64 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib64/ directory. * Intel Atom 32 bits, the multilib variant is in atom/ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Core 2 64 bits, the multilib variant is in core2/ relative to the main sysroot, with the libraries in lib64/ directory. So the first two variants are in the same sysroot, only the name of the directory for the libraries is different. Therefore, we introduce a new ARCH_LIB_DIR variable, which contains either 'lib' or 'lib64'. This variable is defined according to the location of the libc.a file for the selected multilib variant, and is then used when copying the libraries to the target and to the staging directory. In addition to this, we no longer use the -print-multi-directory to get the ARCH_SUBDIR, since in the case of the 64 bits variants of this toolchain, it returns just '64' and not a real path. Instead, we simply compute the difference between the arch-specific sysroot and the main sysroot. We also take that opportunity to expand the documentation on the meaning of the different variables. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2011-12-31 11:57:15 +01:00
toolchain-external: align library locations in target and staging dir The toolchain-external logic is roughly: - populate the staging dir by rsyncing the entire ${ARCH_LIB_DIR} and usr/${ARCH_LIB_DIR} from sysroot. - populate the target dir by explictly copying some libraries from sysroot into target/lib and some other libraries in target/usr/lib, the split being hardcoded into buildroot regardless of the location in the sysroot. This means that a library libfoo could be located in: staging/lib/libfoo.so target/usr/lib/libfoo.so When debugging an application that links against this library, gdb will fruitlessly search for 'usr/lib/libfoo.so' in staging, and then suggest to use 'set solib-search-path' which is a hack, really. To solve the problem, we need to make sure that libraries from the toolchain are installed in the same relative location in staging and target. Achieve this by: - replacing the convoluted search for libraries using for+find in sysroot with a simple find in staging. - determining DESTDIR for each library individually based on the location in staging. - treating LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS equivalently These changes also allow for the removal of most arguments to copy_toolchain_lib_root in the method itself and their callers. Test procedure: - set configuration for a given toolchain - make clean toolchain - find output/target | sort > /tmp/out-before - apply patch - make clean toolchain - find output/target | sort > /tmp/out-after - diff -u /tmp/out-before /tmp/out-after The only changes should be some libraries moving from lib to usr/lib or vice versa. Notable examples being libstdc++ and libatomic. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: - use -L instead of -follow in the find invocation, as suggested by Arnout. - move the BR2_STATIC_LIBS condition as a make condition rather than a shell condition, as suggested by Arnout.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-12 20:20:25 +01:00
ifeq ($(BR2_STATIC_LIBS),)
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS
$(Q)$(call MESSAGE,"Copying external toolchain libraries to target...")
$(Q)for libs in $(TOOLCHAIN_EXTERNAL_LIBS); do \
toolchain-external: align library locations in target and staging dir The toolchain-external logic is roughly: - populate the staging dir by rsyncing the entire ${ARCH_LIB_DIR} and usr/${ARCH_LIB_DIR} from sysroot. - populate the target dir by explictly copying some libraries from sysroot into target/lib and some other libraries in target/usr/lib, the split being hardcoded into buildroot regardless of the location in the sysroot. This means that a library libfoo could be located in: staging/lib/libfoo.so target/usr/lib/libfoo.so When debugging an application that links against this library, gdb will fruitlessly search for 'usr/lib/libfoo.so' in staging, and then suggest to use 'set solib-search-path' which is a hack, really. To solve the problem, we need to make sure that libraries from the toolchain are installed in the same relative location in staging and target. Achieve this by: - replacing the convoluted search for libraries using for+find in sysroot with a simple find in staging. - determining DESTDIR for each library individually based on the location in staging. - treating LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS equivalently These changes also allow for the removal of most arguments to copy_toolchain_lib_root in the method itself and their callers. Test procedure: - set configuration for a given toolchain - make clean toolchain - find output/target | sort > /tmp/out-before - apply patch - make clean toolchain - find output/target | sort > /tmp/out-after - diff -u /tmp/out-before /tmp/out-after The only changes should be some libraries moving from lib to usr/lib or vice versa. Notable examples being libstdc++ and libatomic. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: - use -L instead of -follow in the find invocation, as suggested by Arnout. - move the BR2_STATIC_LIBS condition as a make condition rather than a shell condition, as suggested by Arnout.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-12 20:20:25 +01:00
$(call copy_toolchain_lib_root,$$libs); \
done
endef
toolchain-external: align library locations in target and staging dir The toolchain-external logic is roughly: - populate the staging dir by rsyncing the entire ${ARCH_LIB_DIR} and usr/${ARCH_LIB_DIR} from sysroot. - populate the target dir by explictly copying some libraries from sysroot into target/lib and some other libraries in target/usr/lib, the split being hardcoded into buildroot regardless of the location in the sysroot. This means that a library libfoo could be located in: staging/lib/libfoo.so target/usr/lib/libfoo.so When debugging an application that links against this library, gdb will fruitlessly search for 'usr/lib/libfoo.so' in staging, and then suggest to use 'set solib-search-path' which is a hack, really. To solve the problem, we need to make sure that libraries from the toolchain are installed in the same relative location in staging and target. Achieve this by: - replacing the convoluted search for libraries using for+find in sysroot with a simple find in staging. - determining DESTDIR for each library individually based on the location in staging. - treating LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS equivalently These changes also allow for the removal of most arguments to copy_toolchain_lib_root in the method itself and their callers. Test procedure: - set configuration for a given toolchain - make clean toolchain - find output/target | sort > /tmp/out-before - apply patch - make clean toolchain - find output/target | sort > /tmp/out-after - diff -u /tmp/out-before /tmp/out-after The only changes should be some libraries moving from lib to usr/lib or vice versa. Notable examples being libstdc++ and libatomic. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: - use -L instead of -follow in the find invocation, as suggested by Arnout. - move the BR2_STATIC_LIBS condition as a make condition rather than a shell condition, as suggested by Arnout.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-12 20:20:25 +01:00
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 ; \
ARCH_SUBDIR=`echo $${ARCH_SYSROOT_DIR} | sed -r -e "s:^$${SYSROOT_DIR}(.*)/$$:\1:"` ; \
$(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
# Special installation target used on the Blackfin architecture when
# FDPIC is not the primary binary format being used, but the user has
# nonetheless requested the installation of the FDPIC libraries to the
# target filesystem.
ifeq ($(BR2_BFIN_INSTALL_FDPIC_SHARED),y)
define TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS_BFIN_FDPIC
$(Q)$(call MESSAGE,"Install external toolchain FDPIC libraries to staging...")
$(Q)FDPIC_EXTERNAL_CC=$(dir $(TOOLCHAIN_EXTERNAL_CC))/../../bfin-linux-uclibc/bin/bfin-linux-uclibc-gcc ; \
FDPIC_SYSROOT_DIR="$(call toolchain_find_sysroot,$${FDPIC_EXTERNAL_CC} $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
FDPIC_LIB_DIR="$(call toolchain_find_libdir,$${FDPIC_EXTERNAL_CC} $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
FDPIC_SUPPORT_LIB_DIR="" ; \
if test `find $${FDPIC_SYSROOT_DIR} -name 'libstdc++.a' | wc -l` -eq 0 ; then \
FDPIC_LIBSTDCPP_A_LOCATION=$$(LANG=C $${FDPIC_EXTERNAL_CC} $(TOOLCHAIN_EXTERNAL_CFLAGS) -print-file-name=libstdc++.a) ; \
if [ -e "$${FDPIC_LIBSTDCPP_A_LOCATION}" ]; then \
FDPIC_SUPPORT_LIB_DIR=`readlink -f $${FDPIC_LIBSTDCPP_A_LOCATION} | sed -r -e 's:libstdc\+\+\.a::'` ; \
fi ; \
fi ; \
$(call copy_toolchain_sysroot,$${FDPIC_SYSROOT_DIR},$${FDPIC_SYSROOT_DIR},,$${FDPIC_LIB_DIR},$${FDPIC_SUPPORT_LIB_DIR})
endef
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FDPIC
$(Q)$(call MESSAGE,"Install external toolchain FDPIC libraries to target...")
$(Q)for libs in $(TOOLCHAIN_EXTERNAL_LIBS); do \
toolchain-external: align library locations in target and staging dir The toolchain-external logic is roughly: - populate the staging dir by rsyncing the entire ${ARCH_LIB_DIR} and usr/${ARCH_LIB_DIR} from sysroot. - populate the target dir by explictly copying some libraries from sysroot into target/lib and some other libraries in target/usr/lib, the split being hardcoded into buildroot regardless of the location in the sysroot. This means that a library libfoo could be located in: staging/lib/libfoo.so target/usr/lib/libfoo.so When debugging an application that links against this library, gdb will fruitlessly search for 'usr/lib/libfoo.so' in staging, and then suggest to use 'set solib-search-path' which is a hack, really. To solve the problem, we need to make sure that libraries from the toolchain are installed in the same relative location in staging and target. Achieve this by: - replacing the convoluted search for libraries using for+find in sysroot with a simple find in staging. - determining DESTDIR for each library individually based on the location in staging. - treating LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS equivalently These changes also allow for the removal of most arguments to copy_toolchain_lib_root in the method itself and their callers. Test procedure: - set configuration for a given toolchain - make clean toolchain - find output/target | sort > /tmp/out-before - apply patch - make clean toolchain - find output/target | sort > /tmp/out-after - diff -u /tmp/out-before /tmp/out-after The only changes should be some libraries moving from lib to usr/lib or vice versa. Notable examples being libstdc++ and libatomic. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: - use -L instead of -follow in the find invocation, as suggested by Arnout. - move the BR2_STATIC_LIBS condition as a make condition rather than a shell condition, as suggested by Arnout.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-12 20:20:25 +01:00
$(call copy_toolchain_lib_root,$$libs); \
done
endef
endif
# Special installation target used on the Blackfin architecture when
# shared FLAT is not the primary format being used, but the user has
# nonetheless requested the installation of the shared FLAT libraries
# to the target filesystem. The flat libraries are found and linked
# according to the index in name "libN.so". Index 1 is reserved for
# the standard C library. Customer libraries can use 4 and above.
ifeq ($(BR2_BFIN_INSTALL_FLAT_SHARED),y)
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FLAT
$(Q)$(call MESSAGE,"Install external toolchain FLAT libraries to target...")
$(Q)FLAT_EXTERNAL_CC=$(dir $(TOOLCHAIN_EXTERNAL_CC))../../bfin-uclinux/bin/bfin-uclinux-gcc ; \
FLAT_LIBC_A_LOCATION=`$${FLAT_EXTERNAL_CC} $(TOOLCHAIN_EXTERNAL_CFLAGS) -mid-shared-library -print-file-name=libc`; \
if [ -f $${FLAT_LIBC_A_LOCATION} -a ! -h $${FLAT_LIBC_A_LOCATION} ] ; then \
$(INSTALL) -D $${FLAT_LIBC_A_LOCATION} $(TARGET_DIR)/lib/lib1.so; \
fi
endef
endif
# Build toolchain wrapper for preprocessor, C, C++ and Fortran compilers
# and setup symlinks for everything else. Skip gdb symlink when we are
# building our own gdb to prevent two gdb's in output/host/usr/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
toolchain-external: trivial clean up of messages Before this commit, the output of the toolchain-external build steps looked like this (abbreviated for clarity): >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper mkdir -p output/host/usr/bin; cd output/host/usr/bin; for i in ... /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... if test -f output/host/usr/bin/i686-pc-linux-gnu-gdb ; then mkdir -p ... >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... if test -e output/target/lib/ld-uClibc.so.1; then ln -sf ld-uClibc.so.1 output/target/lib/ld-uClibc.so.0 ; fi if test -e output/target/lib/ld64-uClibc.so.1; then ln -sf ld64-uClibc.so.1 output/target/lib/ld64-uClibc.so.0 ; fi All the long lines with conditions and loops in them are not usefull, so put $(Q) in front of them. The line with mkdir can better be split on a separate line so the cd stands out more. There are two redundant semicolons that can be removed. The installation of gdbinit could use an extra message so the user can see what is going on. After this commit, the toolchain-external build steps look like this: >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... >>> toolchain-external undefined Installing gdbinit >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-11 22:57:58 +02:00
$(Q)cd $(HOST_DIR)/usr/bin; \
for i in $(TOOLCHAIN_EXTERNAL_CROSS)*; do \
base=$${i##*/}; \
case "$$base" in \
toolchain: add link-time-optimization support Add a new option BR2_GCC_ENABLE_LTO that builds gcc and binutils with LTO support. Individual packages still have to enable LTO explicitly by passing '-flto' to GCC, which passes it on to the linker. This option does not add that flag globally. Some packages detect if the compiler supports LTO and enable the flag if it does. To support LTO, ar and ranlib must be called with an argument which triggers the usage of the LTO plugin. Since GCC doesn't call these tools itself, it instead provides wrappers for ar and ranlib that pass the LTO arguments. This way existing Makefiles don't need to be changed for LTO support. However, these wrappers are called <tuple>-gcc-ar which matches the pattern to link to the buildroot wrapper in the external toolchain logic. So the external toolchain logic is updated to provide the correct symlink. [Thomas: - Add a separate BR2_BINUTILS_ENABLE_LTO option to enable LTO support in binutils. This is a blind option, selected by BR2_GCC_ENABLE_LTO. It just avoids having binutils.mk poke directly into gcc Config.in options. - Remove the check on the AVR32 special gcc version, which we don't support anymore. - Adapt the help text of the LTO Config.in option to no longer mention "Since version 4.5", since we only support gcc >= 4.5 in Buildroot anyway. - Fix typo in toolchain-external.mk comment.] Signed-off-by: Peter Kümmel <syntheticpp@gmx.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-06 13:34:06 +01:00
*-ar|*-ranlib|*-nm) \
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%../..%') .; \
;; \
*cc|*cc-*|*++|*++-*|*cpp|*-gfortran) \
ln -sf toolchain-wrapper $$base; \
;; \
*gdb|*gdbtui) \
if test "$(BR2_PACKAGE_HOST_GDB)" != "y"; then \
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%../..%') .; \
fi \
;; \
*) \
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%../..%') .; \
;; \
esac; \
toolchain-external: trivial clean up of messages Before this commit, the output of the toolchain-external build steps looked like this (abbreviated for clarity): >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper mkdir -p output/host/usr/bin; cd output/host/usr/bin; for i in ... /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... if test -f output/host/usr/bin/i686-pc-linux-gnu-gdb ; then mkdir -p ... >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... if test -e output/target/lib/ld-uClibc.so.1; then ln -sf ld-uClibc.so.1 output/target/lib/ld-uClibc.so.0 ; fi if test -e output/target/lib/ld64-uClibc.so.1; then ln -sf ld64-uClibc.so.1 output/target/lib/ld64-uClibc.so.0 ; fi All the long lines with conditions and loops in them are not usefull, so put $(Q) in front of them. The line with mkdir can better be split on a separate line so the cd stands out more. There are two redundant semicolons that can be removed. The installation of gdbinit could use an extra message so the user can see what is going on. After this commit, the toolchain-external build steps look like this: >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... >>> toolchain-external undefined Installing gdbinit >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-11 22:57:58 +02:00
done
endef
toolchain-external: trivial clean up of messages Before this commit, the output of the toolchain-external build steps looked like this (abbreviated for clarity): >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper mkdir -p output/host/usr/bin; cd output/host/usr/bin; for i in ... /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... if test -f output/host/usr/bin/i686-pc-linux-gnu-gdb ; then mkdir -p ... >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... if test -e output/target/lib/ld-uClibc.so.1; then ln -sf ld-uClibc.so.1 output/target/lib/ld-uClibc.so.0 ; fi if test -e output/target/lib/ld64-uClibc.so.1; then ln -sf ld64-uClibc.so.1 output/target/lib/ld64-uClibc.so.0 ; fi All the long lines with conditions and loops in them are not usefull, so put $(Q) in front of them. The line with mkdir can better be split on a separate line so the cd stands out more. There are two redundant semicolons that can be removed. The installation of gdbinit could use an extra message so the user can see what is going on. After this commit, the toolchain-external build steps look like this: >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... >>> toolchain-external undefined Installing gdbinit >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-11 22:57:58 +02:00
#
# Generate gdbinit file for use with Buildroot
#
define TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT
toolchain-external: trivial clean up of messages Before this commit, the output of the toolchain-external build steps looked like this (abbreviated for clarity): >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper mkdir -p output/host/usr/bin; cd output/host/usr/bin; for i in ... /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... if test -f output/host/usr/bin/i686-pc-linux-gnu-gdb ; then mkdir -p ... >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... if test -e output/target/lib/ld-uClibc.so.1; then ln -sf ld-uClibc.so.1 output/target/lib/ld-uClibc.so.0 ; fi if test -e output/target/lib/ld64-uClibc.so.1; then ln -sf ld64-uClibc.so.1 output/target/lib/ld64-uClibc.so.0 ; fi All the long lines with conditions and loops in them are not usefull, so put $(Q) in front of them. The line with mkdir can better be split on a separate line so the cd stands out more. There are two redundant semicolons that can be removed. The installation of gdbinit could use an extra message so the user can see what is going on. After this commit, the toolchain-external build steps look like this: >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... >>> toolchain-external undefined Installing gdbinit >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-11 22:57:58 +02:00
$(Q)if test -f $(TARGET_CROSS)gdb ; then \
$(call MESSAGE,"Installing gdbinit"); \
$(gen_gdbinit_file); \
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
toolchain-external: trivial clean up of messages Before this commit, the output of the toolchain-external build steps looked like this (abbreviated for clarity): >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper mkdir -p output/host/usr/bin; cd output/host/usr/bin; for i in ... /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... if test -f output/host/usr/bin/i686-pc-linux-gnu-gdb ; then mkdir -p ... >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... if test -e output/target/lib/ld-uClibc.so.1; then ln -sf ld-uClibc.so.1 output/target/lib/ld-uClibc.so.0 ; fi if test -e output/target/lib/ld64-uClibc.so.1; then ln -sf ld64-uClibc.so.1 output/target/lib/ld64-uClibc.so.0 ; fi All the long lines with conditions and loops in them are not usefull, so put $(Q) in front of them. The line with mkdir can better be split on a separate line so the cd stands out more. There are two redundant semicolons that can be removed. The installation of gdbinit could use an extra message so the user can see what is going on. After this commit, the toolchain-external build steps look like this: >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... >>> toolchain-external undefined Installing gdbinit >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-11 22:57:58 +02:00
$(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
toolchain-external: trivial clean up of messages Before this commit, the output of the toolchain-external build steps looked like this (abbreviated for clarity): >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper mkdir -p output/host/usr/bin; cd output/host/usr/bin; for i in ... /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... if test -f output/host/usr/bin/i686-pc-linux-gnu-gdb ; then mkdir -p ... >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... if test -e output/target/lib/ld-uClibc.so.1; then ln -sf ld-uClibc.so.1 output/target/lib/ld-uClibc.so.0 ; fi if test -e output/target/lib/ld64-uClibc.so.1; then ln -sf ld64-uClibc.so.1 output/target/lib/ld64-uClibc.so.0 ; fi All the long lines with conditions and loops in them are not usefull, so put $(Q) in front of them. The line with mkdir can better be split on a separate line so the cd stands out more. There are two redundant semicolons that can be removed. The installation of gdbinit could use an extra message so the user can see what is going on. After this commit, the toolchain-external build steps look like this: >>> toolchain-external undefined Building >>> toolchain-external undefined Installing to staging directory >>> toolchain-external undefined Copying external toolchain sysroot to staging... >>> toolchain-external undefined Building ext-toolchain wrapper /usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='... >>> toolchain-external undefined Installing gdbinit >>> toolchain-external undefined Fixing libtool files >>> toolchain-external undefined Installing to target >>> toolchain-external undefined Copying external toolchain libraries to target... Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-11 22:57:58 +02:00
$(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_BUILD_CMDS = $(TOOLCHAIN_BUILD_WRAPPER)
define TOOLCHAIN_EXTERNAL_INSTALL_STAGING_CMDS
toolchain-external: create symlink ARCH_LIB_DIR->lib Currently, following symbolic links are created in both target and staging directories: - lib(32|64) --> lib - usr/lib(32|64) --> lib The decision for lib32 or lib64 is based on the target architecture configuration in buildroot (BR2_ARCH_IS_64). In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (ABI=n32; likewise for lib64-fp in case of ABI=n64) More generally the correct symbolic link is from (usr/)${ARCH_LIB_DIR}->lib. However, feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if ARCH_LIB_DIR is different. Hence, these links must be kept. Fix the problem as follows: - For internal toolchains: no change - For external toolchains: create a symlink ARCH_LIB_DIR->lib if (usr/)ARCH_LIB_DIR does not exist yet. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: "Yann E. Morin" <yann.morin.1998@free.fr> Cc: Romain Naour <romain.naour@gmail.com> Cc: Peter Korsgaard <peter@korsgaard.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Tested-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-01-28 13:32:46 +01:00
$(TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK)
$(TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS)
$(TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS_BFIN_FDPIC)
$(TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER)
$(TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT)
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 TOOLCHAIN_EXTERNAL_INSTALL_TARGET_CMDS
toolchain-external: create symlink ARCH_LIB_DIR->lib Currently, following symbolic links are created in both target and staging directories: - lib(32|64) --> lib - usr/lib(32|64) --> lib The decision for lib32 or lib64 is based on the target architecture configuration in buildroot (BR2_ARCH_IS_64). In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (ABI=n32; likewise for lib64-fp in case of ABI=n64) More generally the correct symbolic link is from (usr/)${ARCH_LIB_DIR}->lib. However, feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if ARCH_LIB_DIR is different. Hence, these links must be kept. Fix the problem as follows: - For internal toolchains: no change - For external toolchains: create a symlink ARCH_LIB_DIR->lib if (usr/)ARCH_LIB_DIR does not exist yet. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: "Yann E. Morin" <yann.morin.1998@free.fr> Cc: Romain Naour <romain.naour@gmail.com> Cc: Peter Korsgaard <peter@korsgaard.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Tested-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-01-28 13:32:46 +01:00
$(TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK)
$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS)
$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER)
$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FDPIC)
$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FLAT)
$(TOOLCHAIN_EXTERNAL_FIXUP_UCLIBCNG_LDSO)
endef
$(eval $(generic-package))