2013-10-08 20:17:03 +02:00
|
|
|
################################################################################
|
2009-07-17 00:20:33 +02:00
|
|
|
#
|
2013-10-08 20:17:03 +02:00
|
|
|
# toolchain-external
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# This package implements the support for external toolchains, i.e
|
2015-02-20 09:19:21 +01:00
|
|
|
# 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
|
2010-12-13 17:27:39 +01:00
|
|
|
# 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
|
2013-11-07 00:08:02 +01:00
|
|
|
# * 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
|
2015-03-10 12:50:24 +01:00
|
|
|
# * Synopsys DesignWare toolchains for ARC cores
|
2009-07-17 00:20:33 +02:00
|
|
|
#
|
|
|
|
|
# The basic principle is the following
|
|
|
|
|
#
|
2012-06-22 07:42:39 +02:00
|
|
|
# 1. If the toolchain is not pre-installed, download and extract it
|
2013-11-07 00:08:02 +01:00
|
|
|
# in $(TOOLCHAIN_EXTERNAL_INSTALL_DIR). Otherwise,
|
|
|
|
|
# $(TOOLCHAIN_EXTERNAL_INSTALL_DIR) points to were the toolchain has
|
|
|
|
|
# already been installed by the user.
|
2010-12-13 17:27:39 +01:00
|
|
|
#
|
2012-06-22 07:42:39 +02:00
|
|
|
# 2. For all external toolchains, perform some checks on the
|
2010-12-13 17:27:39 +01:00
|
|
|
# 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
|
2012-11-03 18:47:49 +01:00
|
|
|
# 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.
|
2009-07-17 00:20:33 +02:00
|
|
|
#
|
2012-06-22 07:42:39 +02:00
|
|
|
# 3. Copy the libraries needed at runtime to the target directory,
|
2009-07-17 00:20:33 +02:00
|
|
|
# $(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.
|
|
|
|
|
#
|
2012-06-22 07:42:39 +02:00
|
|
|
# 4. Copy the libraries and headers to the staging directory. This
|
2009-07-17 00:20:33 +02:00
|
|
|
# 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.
|
2011-04-29 13:09:26 +02:00
|
|
|
#
|
2012-06-22 07:42:39 +02:00
|
|
|
# 5. Build a toolchain wrapper which executes the external toolchain
|
2011-04-29 13:09:26 +02:00
|
|
|
# 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.
|
2009-07-17 00:20:33 +02:00
|
|
|
|
toolchain-external: conditionalize the installation of libraries
The external toolchain code makes the assumption that all C libraries
have a ld*.so, libc.so, libcrypt.so, libdl.so, libgcc_s.so, libm.so,
libnsl.so, libresolv.so, libutil.so, and when thread support is
enabled, libpthread.so, etc.
However, this is not the case with the musl C library, which
integrates all the functionalities in a single libc.so file. In
preparation of the support of the musl library, we make the current
value of LIB_EXTERNAL_LIBS conditional to glibc or uClibc.
The addition of additional libraries through
BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS is kept outside the condition, at
the end.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-08 20:17:05 +02:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC),y)
|
2016-02-12 20:20:26 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_LIBS += libatomic.so.* libc.so.* libcrypt.so.* libdl.so.* libgcc_s.so.* libm.so.* libnsl.so.* libresolv.so.* librt.so.* libutil.so.*
|
2014-01-14 09:21:35 +01:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC)$(BR2_ARM_EABIHF),yy)
|
2016-02-12 20:20:26 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_LIBS += ld-linux-armhf.so.*
|
2013-10-08 20:17:15 +02:00
|
|
|
else
|
2016-02-12 20:20:26 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_LIBS += ld*.so.*
|
2013-10-08 20:17:15 +02:00
|
|
|
endif
|
toolchain-external: conditionalize the installation of libraries
The external toolchain code makes the assumption that all C libraries
have a ld*.so, libc.so, libcrypt.so, libdl.so, libgcc_s.so, libm.so,
libnsl.so, libresolv.so, libutil.so, and when thread support is
enabled, libpthread.so, etc.
However, this is not the case with the musl C library, which
integrates all the functionalities in a single libc.so file. In
preparation of the support of the musl library, we make the current
value of LIB_EXTERNAL_LIBS conditional to glibc or uClibc.
The addition of additional libraries through
BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS is kept outside the condition, at
the end.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-08 20:17:05 +02:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
|
2016-02-12 20:20:26 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_LIBS += libpthread.so.*
|
2013-10-29 21:54:02 +01:00
|
|
|
ifneq ($(BR2_PACKAGE_GDB)$(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY),)
|
2016-02-12 20:20:26 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_LIBS += libthread_db.so.*
|
toolchain-external: conditionalize the installation of libraries
The external toolchain code makes the assumption that all C libraries
have a ld*.so, libc.so, libcrypt.so, libdl.so, libgcc_s.so, libm.so,
libnsl.so, libresolv.so, libutil.so, and when thread support is
enabled, libpthread.so, etc.
However, this is not the case with the musl C library, which
integrates all the functionalities in a single libc.so file. In
preparation of the support of the musl library, we make the current
value of LIB_EXTERNAL_LIBS conditional to glibc or uClibc.
The addition of additional libraries through
BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS is kept outside the condition, at
the end.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-08 20:17:05 +02:00
|
|
|
endif # gdbserver
|
|
|
|
|
endif # ! no threads
|
|
|
|
|
endif
|
|
|
|
|
|
2010-07-08 22:08:46 +02:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GLIBC),y)
|
2016-10-26 23:47:59 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_LIBS += libnss_files.so.* libnss_dns.so.* libmvec.so.*
|
2009-07-16 23:56:10 +02:00
|
|
|
endif
|
|
|
|
|
|
2013-10-08 20:17:09 +02:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_MUSL),y)
|
2016-02-12 20:20:26 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_LIBS += libc.so libgcc_s.so.*
|
2013-10-08 20:17:09 +02:00
|
|
|
endif
|
|
|
|
|
|
2009-07-17 00:26:23 +02:00
|
|
|
ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
|
2016-02-12 20:20:26 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_LIBS += libstdc++.so.*
|
2009-07-17 00:26:23 +02:00
|
|
|
endif
|
|
|
|
|
|
2016-07-03 15:47:46 +02:00
|
|
|
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
|
|
|
|
|
|
2016-05-13 10:41:31 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_LIBS += $(call qstrip,$(BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS))
|
2010-05-28 23:23:14 +02:00
|
|
|
|
2010-12-13 17:27:39 +01:00
|
|
|
# Details about sysroot directory selection.
|
|
|
|
|
#
|
2013-11-07 00:08:02 +01:00
|
|
|
# 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
|
2015-02-14 10:23:09 +01:00
|
|
|
# only available since gcc 4.4.x, and we only recently dropped support
|
|
|
|
|
# for 4.2.x and 4.3.x.
|
2013-11-07 00:08:02 +01:00
|
|
|
#
|
|
|
|
|
# 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.
|
2010-12-13 17:27:39 +01:00
|
|
|
#
|
|
|
|
|
# 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.
|
|
|
|
|
|
2011-04-29 13:09:26 +02:00
|
|
|
|
.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
|
|
|
|
|
|
2011-04-29 13:09:26 +02:00
|
|
|
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)
|
2011-04-29 13:09:26 +02:00
|
|
|
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))
|
2011-04-29 13:09:26 +02:00
|
|
|
endif
|
|
|
|
|
|
2013-10-08 20:17:03 +02:00
|
|
|
ifeq ($(TOOLCHAIN_EXTERNAL_INSTALL_DIR),)
|
2013-10-06 16:19:13 +02:00
|
|
|
ifneq ($(TOOLCHAIN_EXTERNAL_PREFIX),)
|
2011-04-29 13:09:26 +02:00
|
|
|
# if no path set, figure it out from path
|
2013-07-20 08:52:43 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_BIN := $(shell dirname $(shell which $(TOOLCHAIN_EXTERNAL_PREFIX)-gcc))
|
2013-10-06 16:19:13 +02:00
|
|
|
endif
|
2011-04-29 13:09:26 +02:00
|
|
|
else
|
2015-12-19 19:14:44 +01:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX),y)
|
2013-10-08 20:17:03 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_BIN := $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/$(TOOLCHAIN_EXTERNAL_PREFIX)/bin
|
2013-06-08 11:14:22 +02:00
|
|
|
else
|
2013-10-08 20:17:03 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_BIN := $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/bin
|
2011-04-29 13:09:26 +02:00
|
|
|
endif
|
2013-06-08 11:14:22 +02:00
|
|
|
endif
|
2011-04-29 13:09:26 +02:00
|
|
|
|
2015-10-14 23:05:55 +02:00
|
|
|
# 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)-
|
2015-10-14 23:05:55 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_CC = $(TOOLCHAIN_EXTERNAL_CROSS)gcc$(TOOLCHAIN_EXTERNAL_SUFFIX)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CXX = $(TOOLCHAIN_EXTERNAL_CROSS)g++$(TOOLCHAIN_EXTERNAL_SUFFIX)
|
2016-07-03 15:47:45 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_FC = $(TOOLCHAIN_EXTERNAL_CROSS)gfortran$(TOOLCHAIN_EXTERNAL_SUFFIX)
|
2015-10-14 23:05:55 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_READELF = $(TOOLCHAIN_EXTERNAL_CROSS)readelf$(TOOLCHAIN_EXTERNAL_SUFFIX)
|
2012-07-15 03:12:05 +02:00
|
|
|
|
|
|
|
|
ifeq ($(filter $(HOST_DIR)/%,$(TOOLCHAIN_EXTERNAL_BIN)),)
|
|
|
|
|
# TOOLCHAIN_EXTERNAL_BIN points outside HOST_DIR => absolute path
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += \
|
2012-07-15 03:12:05 +02:00
|
|
|
-DBR_CROSS_PATH_ABS='"$(TOOLCHAIN_EXTERNAL_BIN)"'
|
|
|
|
|
else
|
|
|
|
|
# TOOLCHAIN_EXTERNAL_BIN points inside HOST_DIR => relative path
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += \
|
2012-07-15 03:12:05 +02:00
|
|
|
-DBR_CROSS_PATH_REL='"$(TOOLCHAIN_EXTERNAL_BIN:$(HOST_DIR)/%=%)"'
|
|
|
|
|
endif
|
2011-04-29 13:09:26 +02:00
|
|
|
|
2013-05-03 02:39:36 +02:00
|
|
|
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))
|
2013-05-03 02:39:36 +02:00
|
|
|
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))
|
2013-05-03 02:39:36 +02:00
|
|
|
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))
|
2011-05-02 23:58:20 +02:00
|
|
|
|
2011-04-29 13:09:26 +02:00
|
|
|
# march/mtune/floating point mode needs to be passed to the external toolchain
|
|
|
|
|
# to select the right multilib variant
|
2012-03-13 23:30:00 +01:00
|
|
|
ifeq ($(BR2_x86_64),y)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -m64
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_64
|
2012-03-13 23:30:00 +01:00
|
|
|
endif
|
2011-04-29 13:09:26 +02:00
|
|
|
ifneq ($(CC_TARGET_ARCH_),)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -march=$(CC_TARGET_ARCH_)
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_ARCH='"$(CC_TARGET_ARCH_)"'
|
2011-04-29 13:09:26 +02:00
|
|
|
endif
|
2011-11-01 13:19:16 +01:00
|
|
|
ifneq ($(CC_TARGET_CPU_),)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -mcpu=$(CC_TARGET_CPU_)
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_CPU='"$(CC_TARGET_CPU_)"'
|
2011-11-01 13:19:16 +01:00
|
|
|
endif
|
2011-04-29 13:09:26 +02:00
|
|
|
ifneq ($(CC_TARGET_ABI_),)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -mabi=$(CC_TARGET_ABI_)
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_ABI='"$(CC_TARGET_ABI_)"'
|
2011-04-29 13:09:26 +02:00
|
|
|
endif
|
arch: introduce BR2_GCC_TARGET_{FPU, FLOAT_ABI}
Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.
This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:12 +02:00
|
|
|
ifneq ($(CC_TARGET_FPU_),)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -mfpu=$(CC_TARGET_FPU_)
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_FPU='"$(CC_TARGET_FPU_)"'
|
arch: introduce BR2_GCC_TARGET_{FPU, FLOAT_ABI}
Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.
This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:12 +02:00
|
|
|
endif
|
|
|
|
|
ifneq ($(CC_TARGET_FLOAT_ABI_),)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -mfloat-abi=$(CC_TARGET_FLOAT_ABI_)
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_FLOAT_ABI='"$(CC_TARGET_FLOAT_ABI_)"'
|
arch: introduce BR2_GCC_TARGET_{FPU, FLOAT_ABI}
Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.
This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:12 +02:00
|
|
|
endif
|
2013-07-16 10:03:22 +02:00
|
|
|
ifneq ($(CC_TARGET_MODE_),)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -m$(CC_TARGET_MODE_)
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_MODE='"$(CC_TARGET_MODE_)"'
|
2013-07-16 10:03:22 +02:00
|
|
|
endif
|
2013-05-03 02:39:34 +02:00
|
|
|
ifeq ($(BR2_BINFMT_FLAT),y)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -Wl,-elf2flt
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_BINFMT_FLAT
|
2013-05-03 02:39:34 +02:00
|
|
|
endif
|
2013-10-14 11:52:25 +02:00
|
|
|
ifeq ($(BR2_mipsel)$(BR2_mips64el),y)
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_MIPS_TARGET_LITTLE_ENDIAN
|
2013-10-14 11:52:25 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -EL
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_mips)$(BR2_mips64),y)
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_MIPS_TARGET_BIG_ENDIAN
|
2013-10-14 11:52:25 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -EB
|
|
|
|
|
endif
|
2015-03-10 12:50:24 +01:00
|
|
|
ifeq ($(BR2_arceb),y)
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_ARC_TARGET_BIG_ENDIAN
|
2015-03-10 12:50:24 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -EB
|
|
|
|
|
endif
|
2015-10-04 14:28:41 +02:00
|
|
|
|
2011-12-31 12:09:33 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += $(call qstrip,$(BR2_TARGET_OPTIMIZATION))
|
|
|
|
|
|
2011-04-29 13:09:26 +02:00
|
|
|
ifeq ($(BR2_SOFT_FLOAT),y)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_CFLAGS += -msoft-float
|
2015-10-04 14:28:41 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_SOFTFLOAT=1
|
2011-04-29 13:09:26 +02:00
|
|
|
endif
|
|
|
|
|
|
2016-08-18 23:50:13 +02:00
|
|
|
# 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
|
2015-12-02 01:58:28 +01:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
|
2016-08-18 23:50:13 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_DEPENDENCIES += musl-compat-headers
|
2015-12-02 01:58:28 +01:00
|
|
|
endif
|
|
|
|
|
|
2016-05-10 16:01:38 +02:00
|
|
|
# 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
|
|
|
|
|
|
2016-03-28 15:37:35 +02:00
|
|
|
# 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
|
|
|
|
|
|
2015-10-24 14:48:57 +02:00
|
|
|
# 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
|
|
|
|
|
|
2015-12-19 19:14:40 +01:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM),y)
|
2015-03-09 23:14:51 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = http://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi
|
2014-09-15 23:49:35 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = arm-2014.05-29-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
|
2015-12-19 19:14:46 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_ARAGO_ARMV7A),y)
|
2015-03-09 23:14:51 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/exports
|
2013-07-20 08:52:43 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = arago-2011.09-armv7a-linux-gnueabi-sdk.tar.bz2
|
2015-10-03 23:18:20 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_ACTUAL_SOURCE_TARBALL = arago-toolchain-2011.09-sources.tar.bz2
|
2013-06-08 11:14:17 +02:00
|
|
|
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/
|
2013-06-08 11:14:17 +02:00
|
|
|
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
|
2015-12-19 19:14:46 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_ARAGO_ARMV5TE),y)
|
2015-03-09 23:14:51 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/exports
|
2013-07-20 08:52:43 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = arago-2011.09-armv5te-linux-gnueabi-sdk.tar.bz2
|
2015-10-03 23:18:20 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_ACTUAL_SOURCE_TARBALL = arago-toolchain-2011.09-sources.tar.bz2
|
2013-06-08 11:14:18 +02:00
|
|
|
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/
|
2013-06-08 11:14:18 +02:00
|
|
|
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
|
2014-06-01 12:47:40 +02:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM),y)
|
2016-10-11 23:04:57 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/arm-linux-gnueabihf
|
2015-10-27 00:49:39 +01:00
|
|
|
ifeq ($(HOSTARCH),x86)
|
2016-10-11 23:04:57 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-i686_arm-linux-gnueabihf.tar.xz
|
2015-10-27 00:49:39 +01:00
|
|
|
else
|
2016-09-24 11:37:51 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf.tar.xz
|
2015-10-27 00:49:39 +01:00
|
|
|
endif
|
2014-03-05 23:23:40 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_ARMEB),y)
|
2016-10-11 23:04:58 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/armeb-linux-gnueabihf
|
2015-10-27 00:49:40 +01:00
|
|
|
ifeq ($(HOSTARCH),x86)
|
2016-10-11 23:04:58 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-i686_armeb-linux-gnueabihf.tar.xz
|
2015-10-27 00:49:40 +01:00
|
|
|
else
|
2016-09-24 11:37:52 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-x86_64_armeb-linux-gnueabihf.tar.xz
|
2015-10-27 00:49:40 +01:00
|
|
|
endif
|
2015-11-21 17:36:19 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS),y)
|
2015-06-04 18:03:43 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = http://sourcery.mentor.com/public/gnu_toolchain/mips-linux-gnu
|
2016-04-30 23:10:25 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = mips-2016.05-8-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2
|
2015-11-21 17:36:16 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII),y)
|
2015-03-09 23:14:51 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = http://sourcery.mentor.com/public/gnu_toolchain/nios2-linux-gnu
|
2016-05-19 00:23:30 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = sourceryg++-2016.05-10-nios2-linux-gnu-i686-pc-linux-gnu.tar.bz2
|
2015-12-19 19:14:42 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_SH),y)
|
2015-03-09 23:14:51 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = https://sourcery.mentor.com/public/gnu_toolchain/sh-linux-gnu
|
2013-07-20 08:52:43 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = renesas-2012.09-61-sh-linux-gnu-i686-pc-linux-gnu.tar.bz2
|
2015-12-19 19:14:43 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_X86),y)
|
2015-03-09 23:14:51 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = https://sourcery.mentor.com/public/gnu_toolchain/i686-pc-linux-gnu
|
2013-07-20 08:52:43 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = ia32-2012.09-62-i686-pc-linux-gnu-i386-linux.tar.bz2
|
2015-11-21 17:36:14 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_AMD64),y)
|
2015-03-09 23:14:51 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = https://sourcery.mentor.com/public/gnu_toolchain/x86_64-amd-linux-gnu
|
2016-04-30 23:10:24 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = amd-2015.11-139-x86_64-amd-linux-gnu-i686-pc-linux-gnu.tar.bz2
|
2015-12-15 17:21:25 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESCAPE_IMG_MIPS),y)
|
2016-07-04 12:17:40 +02:00
|
|
|
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
|
2016-05-10 16:01:38 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_SYMLINK
|
2016-03-28 15:37:35 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_STAGING_FIXUPS
|
2015-12-15 17:21:25 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_STRIP_COMPONENTS = 2
|
2015-12-15 17:21:24 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESCAPE_MTI_MIPS),y)
|
2016-07-04 12:17:40 +02:00
|
|
|
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
|
2016-05-10 16:01:38 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_SYMLINK
|
2016-03-28 15:37:35 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESCAPE_MIPS_STAGING_FIXUPS
|
2015-12-15 17:21:24 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_STRIP_COMPONENTS = 2
|
2015-12-19 19:14:44 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX),y)
|
2015-03-09 23:14:51 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = http://downloads.sourceforge.net/project/adi-toolchain/2014R1/2014R1-RC2/i386
|
2014-06-01 12:47:48 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = blackfin-toolchain-2014R1-RC2.i386.tar.bz2
|
|
|
|
|
TOOLCHAIN_EXTERNAL_EXTRA_DOWNLOADS = blackfin-toolchain-uclibc-full-2014R1-RC2.i386.tar.bz2
|
2015-10-24 14:48:57 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_STRIP_COMPONENTS = 3
|
|
|
|
|
TOOLCHAIN_EXTERNAL_POST_EXTRACT_HOOKS += TOOLCHAIN_EXTERNAL_BLACKFIN_UCLIBC_EXTRA_EXTRACT
|
2014-06-01 12:47:41 +02:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64),y)
|
2016-10-11 23:04:59 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/aarch64-linux-gnu
|
2015-10-27 00:49:41 +01:00
|
|
|
ifeq ($(HOSTARCH),x86)
|
2016-10-11 23:04:59 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-i686_aarch64-linux-gnu.tar.xz
|
2015-10-27 00:49:41 +01:00
|
|
|
else
|
2016-09-24 11:37:53 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu.tar.xz
|
2015-10-27 00:49:41 +01:00
|
|
|
endif
|
2014-09-15 23:49:34 +02:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64),y)
|
2015-12-30 15:30:16 +01:00
|
|
|
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
|
2015-05-05 00:01:48 +02:00
|
|
|
define TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64_STAGING_FIXUP
|
2015-12-30 15:30:16 +01:00
|
|
|
ln -sf ld-2.20.so $(STAGING_DIR)/lib/ld-linux-aarch64.so.1
|
2015-05-05 00:01:48 +02:00
|
|
|
endef
|
|
|
|
|
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64_STAGING_FIXUP
|
|
|
|
|
define TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64_TARGET_FIXUP
|
2015-12-30 15:30:16 +01:00
|
|
|
ln -sf ld-2.20.so $(TARGET_DIR)/lib/ld-linux-aarch64.so.1
|
2015-05-05 00:01:48 +02:00
|
|
|
endef
|
2016-05-08 15:05:14 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_POST_INSTALL_TARGET_HOOKS += TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64_TARGET_FIXUP
|
2014-05-05 23:17:10 +02:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_MUSL_CROSS),y)
|
toolchain-external: bump musl toolchain to 1.1.12
While the prebuilt musl toolchains provided by http://musl.codu.org/
had not been updated in a while, a new release based on musl 1.1.12
has been put online in December 2015. This commit updates our external
toolchain package to use this new pre-built toolchain.
Compared to the previous 1.1.6 toolchain, there are some changes:
- The MIPS big endian soft-float variant is no longer available.
- The Microblaze variant is no longer available.
- SuperH 4, both little and big endian, variants have been added.
- The components have been updated: gcc 5.3 is used, binutils 2.25.1,
and of course musl 1.1.12.
Besides the update itself, in this commit, we are:
- Making the musl toolchain non-selectable on MIPS big endian
soft-float.
- Making the musl toolchain actually work on MIPS little endian
soft-float, by downloading the right tarball and setting up the
right symbolic link.
- Removing support for the Microblaze variant, and adding support for
the SH4 variants.
All variants except armeb have been boot tested under Qemu, up to a
Busybox shell prompt. armeb has not been tested due to the lack of a
Qemu configuration for this architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-04 23:50:07 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_VERSION = 1.1.12
|
2015-03-09 23:14:51 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = https://googledrive.com/host/0BwnS5DMB0YQ6bDhPZkpOYVFhbk0/musl-$(TOOLCHAIN_EXTERNAL_VERSION)
|
2015-10-09 11:14:48 +02:00
|
|
|
ifeq ($(BR2_arm)$(BR2_ARM_EABI),yy)
|
2014-06-01 12:47:45 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-arm-linux-musleabi-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
|
2015-10-09 11:14:48 +02:00
|
|
|
else ifeq ($(BR2_arm)$(BR2_ARM_EABIHF),yy)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-arm-linux-musleabihf-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
|
2014-05-05 23:17:10 +02:00
|
|
|
else ifeq ($(BR2_armeb),y)
|
2014-06-01 12:47:45 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-armeb-linux-musleabi-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
|
2014-05-05 23:17:10 +02:00
|
|
|
else ifeq ($(BR2_i386),y)
|
2014-06-01 12:47:45 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-i486-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
|
2014-05-05 23:17:10 +02:00
|
|
|
else ifeq ($(BR2_mips),y)
|
2014-06-01 12:47:45 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-mips-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
|
toolchain-external: bump musl toolchain to 1.1.12
While the prebuilt musl toolchains provided by http://musl.codu.org/
had not been updated in a while, a new release based on musl 1.1.12
has been put online in December 2015. This commit updates our external
toolchain package to use this new pre-built toolchain.
Compared to the previous 1.1.6 toolchain, there are some changes:
- The MIPS big endian soft-float variant is no longer available.
- The Microblaze variant is no longer available.
- SuperH 4, both little and big endian, variants have been added.
- The components have been updated: gcc 5.3 is used, binutils 2.25.1,
and of course musl 1.1.12.
Besides the update itself, in this commit, we are:
- Making the musl toolchain non-selectable on MIPS big endian
soft-float.
- Making the musl toolchain actually work on MIPS little endian
soft-float, by downloading the right tarball and setting up the
right symbolic link.
- Removing support for the Microblaze variant, and adding support for
the SH4 variants.
All variants except armeb have been boot tested under Qemu, up to a
Busybox shell prompt. armeb has not been tested due to the lack of a
Qemu configuration for this architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-04 23:50:07 +01:00
|
|
|
else ifeq ($(BR2_mipsel):$(BR2_SOFT_FLOAT),y:)
|
2014-06-01 12:47:45 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-mipsel-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
|
toolchain-external: bump musl toolchain to 1.1.12
While the prebuilt musl toolchains provided by http://musl.codu.org/
had not been updated in a while, a new release based on musl 1.1.12
has been put online in December 2015. This commit updates our external
toolchain package to use this new pre-built toolchain.
Compared to the previous 1.1.6 toolchain, there are some changes:
- The MIPS big endian soft-float variant is no longer available.
- The Microblaze variant is no longer available.
- SuperH 4, both little and big endian, variants have been added.
- The components have been updated: gcc 5.3 is used, binutils 2.25.1,
and of course musl 1.1.12.
Besides the update itself, in this commit, we are:
- Making the musl toolchain non-selectable on MIPS big endian
soft-float.
- Making the musl toolchain actually work on MIPS little endian
soft-float, by downloading the right tarball and setting up the
right symbolic link.
- Removing support for the Microblaze variant, and adding support for
the SH4 variants.
All variants except armeb have been boot tested under Qemu, up to a
Busybox shell prompt. armeb has not been tested due to the lack of a
Qemu configuration for this architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-04 23:50:07 +01:00
|
|
|
else ifeq ($(BR2_mipsel):$(BR2_SOFT_FLOAT),y:y)
|
|
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-mipsel-sf-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
|
2014-05-05 23:17:10 +02:00
|
|
|
else ifeq ($(BR2_powerpc),y)
|
2014-06-01 12:47:45 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-powerpc-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
|
toolchain-external: bump musl toolchain to 1.1.12
While the prebuilt musl toolchains provided by http://musl.codu.org/
had not been updated in a while, a new release based on musl 1.1.12
has been put online in December 2015. This commit updates our external
toolchain package to use this new pre-built toolchain.
Compared to the previous 1.1.6 toolchain, there are some changes:
- The MIPS big endian soft-float variant is no longer available.
- The Microblaze variant is no longer available.
- SuperH 4, both little and big endian, variants have been added.
- The components have been updated: gcc 5.3 is used, binutils 2.25.1,
and of course musl 1.1.12.
Besides the update itself, in this commit, we are:
- Making the musl toolchain non-selectable on MIPS big endian
soft-float.
- Making the musl toolchain actually work on MIPS little endian
soft-float, by downloading the right tarball and setting up the
right symbolic link.
- Removing support for the Microblaze variant, and adding support for
the SH4 variants.
All variants except armeb have been boot tested under Qemu, up to a
Busybox shell prompt. armeb has not been tested due to the lack of a
Qemu configuration for this architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-04 23:50:07 +01:00
|
|
|
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
|
2014-05-05 23:17:10 +02:00
|
|
|
else ifeq ($(BR2_x86_64),y)
|
2014-06-01 12:47:45 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = crossx86-x86_64-linux-musl-$(TOOLCHAIN_EXTERNAL_VERSION).tar.xz
|
2014-05-05 23:17:10 +02:00
|
|
|
endif
|
2015-12-19 19:14:45 +01:00
|
|
|
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_SYNOPSYS_ARC),y)
|
2015-03-10 12:50:24 +01:00
|
|
|
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
|
2010-12-13 17:27:39 +01:00
|
|
|
else
|
2012-06-22 07:42:38 +02:00
|
|
|
# Custom toolchain
|
2015-10-03 19:22:16 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SITE = $(patsubst %/,%,$(dir $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_URL))))
|
2013-07-20 08:52:43 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_SOURCE = $(notdir $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_URL)))
|
2015-04-23 00:08:39 +02:00
|
|
|
# We can't check hashes for custom downloaded toolchains
|
|
|
|
|
BR_NO_CHECK_HASH_FOR += $(TOOLCHAIN_EXTERNAL_SOURCE)
|
2012-06-22 07:42:38 +02:00
|
|
|
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
|
|
|
|
2015-10-03 23:18:19 +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
|
|
|
|
|
|
2014-02-14 10:55:04 +01:00
|
|
|
TOOLCHAIN_EXTERNAL_ADD_TOOLCHAIN_DEPENDENCY = NO
|
|
|
|
|
|
2013-10-08 20:17:03 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_INSTALL_STAGING = YES
|
|
|
|
|
|
2015-10-24 14:48:57 +02:00
|
|
|
# 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)/
|
2013-10-08 20:17:03 +02:00
|
|
|
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
|
2011-05-30 23:56:56 +02:00
|
|
|
endif
|
2009-07-16 23:56:10 +02:00
|
|
|
|
2013-11-07 00:08:03 +01:00
|
|
|
# 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
|
|
|
|
|
|
2015-02-18 12:36:14 +01:00
|
|
|
# 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.
|
2013-11-07 00:08:03 +01:00
|
|
|
define toolchain_find_sysroot
|
2015-10-03 23:29:57 +02:00
|
|
|
$$(printf $(call toolchain_find_libc_a,$(1)) | sed -r -e 's:(usr/)?lib(32|64)?([^/]*)?/([^/]*/)?libc\.a::')
|
2013-11-07 00:08:03 +01:00
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
# Returns the lib subdirectory for the given compiler + flags (i.e
|
|
|
|
|
# typically lib32 or lib64 for some toolchains)
|
|
|
|
|
define toolchain_find_libdir
|
2015-10-03 23:29:57 +02:00
|
|
|
$$(printf $(call toolchain_find_libc_a,$(1)) | sed -r -e 's:.*/(usr/)?(lib(32|64)?([^/]*)?)/([^/]*/)?libc.a:\2:')
|
2013-11-07 00:08:03 +01:00
|
|
|
endef
|
|
|
|
|
|
2010-12-13 17:27:39 +01:00
|
|
|
# Checks for an already installed toolchain: check the toolchain
|
2016-04-27 22:15:02 +02:00
|
|
|
# location, check that it is usable, and then verify that it
|
2010-12-13 17:27:39 +01:00
|
|
|
# matches the configuration provided in Buildroot: ABI, C++ support,
|
2014-03-01 15:53:01 +01:00
|
|
|
# kernel headers version, type of C library and all C library features.
|
2013-10-08 20:17:03 +02:00
|
|
|
define TOOLCHAIN_EXTERNAL_CONFIGURE_CMDS
|
2011-05-08 18:52:27 +02:00
|
|
|
$(Q)$(call check_cross_compiler_exists,$(TOOLCHAIN_EXTERNAL_CC))
|
toolchain-external: add a specific check to avoid Angstrom toolchains
The Angstrom toolchains available at
http://www.angstrom-distribution.org/toolchains/ are not usable as
external toolchains in Buildroot, because they are not pure toolchains
with just the C library, but instead complete SDKs with many
cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many
more, approximately 200 MB of libraries).
Buildroot cannot use such toolchains, and while this is documented in
our manual, some users still try to do this. Today, one such user came
on the IRC channel, reporting a build problem, which we started
investigating, only to realize after a long time that he was using an
Angstrom toolchain.
To avoid this problem in the future, we explicitly check if the
toolchain is from Angstrom by looking at the vendor part of the tuple
exposed by the toolchain: as soon as it is
<something>-angstrom-<something-else>, we reject the toolchain with an
explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-13 10:28:20 +02:00
|
|
|
$(Q)$(call check_unusable_toolchain,$(TOOLCHAIN_EXTERNAL_CC))
|
2013-11-07 00:08:03 +01:00
|
|
|
$(Q)SYSROOT_DIR="$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC))" ; \
|
2014-06-01 12:47:38 +02:00
|
|
|
$(call check_kernel_headers_version,\
|
2014-06-01 12:47:39 +02:00
|
|
|
$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC)),\
|
2014-06-01 12:47:38 +02:00
|
|
|
$(call qstrip,$(BR2_TOOLCHAIN_HEADERS_AT_LEAST))); \
|
2015-08-04 20:00:35 +02:00
|
|
|
$(call check_gcc_version,$(TOOLCHAIN_EXTERNAL_CC),\
|
|
|
|
|
$(call qstrip,$(BR2_TOOLCHAIN_GCC_AT_LEAST))); \
|
2013-07-17 22:30:49 +02:00
|
|
|
if test "$(BR2_arm)" = "y" ; then \
|
2013-07-17 22:30:48 +02:00
|
|
|
$(call check_arm_abi,\
|
|
|
|
|
"$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS)",\
|
|
|
|
|
$(TOOLCHAIN_EXTERNAL_READELF)) ; \
|
2010-12-13 17:27:39 +01:00
|
|
|
fi ; \
|
2013-07-17 22:30:49 +02:00
|
|
|
if test "$(BR2_INSTALL_LIBSTDCPP)" = "y" ; then \
|
2011-05-08 18:52:27 +02:00
|
|
|
$(call check_cplusplus,$(TOOLCHAIN_EXTERNAL_CXX)) ; \
|
2010-12-13 17:27:39 +01:00
|
|
|
fi ; \
|
2016-07-03 15:47:45 +02:00
|
|
|
if test "$(BR2_TOOLCHAIN_HAS_FORTRAN)" = "y" ; then \
|
|
|
|
|
$(call check_fortran,$(TOOLCHAIN_EXTERNAL_FC)) ; \
|
|
|
|
|
fi ; \
|
2013-07-17 22:30:49 +02:00
|
|
|
if test "$(BR2_TOOLCHAIN_EXTERNAL_UCLIBC)" = "y" ; then \
|
2010-12-13 17:27:39 +01:00
|
|
|
$(call check_uclibc,$${SYSROOT_DIR}) ; \
|
2013-10-08 20:17:09 +02:00
|
|
|
elif test "$(BR2_TOOLCHAIN_EXTERNAL_MUSL)" = "y" ; then \
|
|
|
|
|
$(call check_musl,$${SYSROOT_DIR}) ; \
|
2010-12-13 17:27:39 +01:00
|
|
|
else \
|
|
|
|
|
$(call check_glibc,$${SYSROOT_DIR}) ; \
|
2010-07-05 18:58:58 +02:00
|
|
|
fi
|
2016-03-15 17:40:38 +01:00
|
|
|
$(Q)$(call check_toolchain_ssp,$(TOOLCHAIN_EXTERNAL_CC))
|
2013-10-08 20:17:03 +02:00
|
|
|
endef
|
2010-12-13 17:27:39 +01:00
|
|
|
|
2013-10-08 20:17:09 +02:00
|
|
|
# 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)
|
2014-03-05 23:23:35 +01:00
|
|
|
ifeq ($(BR2_i386),y)
|
|
|
|
|
MUSL_ARCH = i386
|
2015-09-27 15:48:22 +02:00
|
|
|
else ifeq ($(BR2_ARM_EABIHF),y)
|
|
|
|
|
MUSL_ARCH = armhf
|
toolchain-external: bump musl toolchain to 1.1.12
While the prebuilt musl toolchains provided by http://musl.codu.org/
had not been updated in a while, a new release based on musl 1.1.12
has been put online in December 2015. This commit updates our external
toolchain package to use this new pre-built toolchain.
Compared to the previous 1.1.6 toolchain, there are some changes:
- The MIPS big endian soft-float variant is no longer available.
- The Microblaze variant is no longer available.
- SuperH 4, both little and big endian, variants have been added.
- The components have been updated: gcc 5.3 is used, binutils 2.25.1,
and of course musl 1.1.12.
Besides the update itself, in this commit, we are:
- Making the musl toolchain non-selectable on MIPS big endian
soft-float.
- Making the musl toolchain actually work on MIPS little endian
soft-float, by downloading the right tarball and setting up the
right symbolic link.
- Removing support for the Microblaze variant, and adding support for
the SH4 variants.
All variants except armeb have been boot tested under Qemu, up to a
Busybox shell prompt. armeb has not been tested due to the lack of a
Qemu configuration for this architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-04 23:50:07 +01:00
|
|
|
else ifeq ($(BR2_mipsel):$(BR2_SOFT_FLOAT),y:y)
|
|
|
|
|
MUSL_ARCH = mipsel-sf
|
|
|
|
|
else ifeq ($(BR2_sh),y)
|
|
|
|
|
MUSL_ARCH = sh
|
2014-03-05 23:23:35 +01:00
|
|
|
else
|
|
|
|
|
MUSL_ARCH = $(ARCH)
|
|
|
|
|
endif
|
2013-10-08 20:17:09 +02:00
|
|
|
define TOOLCHAIN_EXTERNAL_MUSL_LD_LINK
|
2014-03-05 23:23:35 +01:00
|
|
|
ln -sf libc.so $(TARGET_DIR)/lib/ld-musl-$(MUSL_ARCH).so.1
|
2013-10-08 20:17:09 +02:00
|
|
|
endef
|
|
|
|
|
TOOLCHAIN_EXTERNAL_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_EXTERNAL_MUSL_LD_LINK
|
|
|
|
|
endif
|
|
|
|
|
|
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
|
|
|
|
|
|
2010-12-13 17:27:39 +01:00
|
|
|
# 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
|
2013-07-19 14:25:18 +02:00
|
|
|
# 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
|
2013-07-19 14:25:18 +02:00
|
|
|
# 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/
|
|
|
|
|
#
|
2013-07-19 14:25:18 +02:00
|
|
|
# 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
|
2012-05-07 15:02:19 +02:00
|
|
|
#
|
|
|
|
|
# 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.
|
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
|
|
|
|
2016-02-12 20:20:25 +01:00
|
|
|
ifeq ($(BR2_STATIC_LIBS),)
|
2014-12-01 22:41:37 +01:00
|
|
|
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS
|
2016-04-25 22:53:11 +02:00
|
|
|
$(Q)$(call MESSAGE,"Copying external toolchain libraries to target...")
|
|
|
|
|
$(Q)for libs in $(TOOLCHAIN_EXTERNAL_LIBS); do \
|
2016-02-12 20:20:25 +01:00
|
|
|
$(call copy_toolchain_lib_root,$$libs); \
|
|
|
|
|
done
|
2016-02-12 20:20:24 +01:00
|
|
|
endef
|
2016-02-12 20:20:25 +01:00
|
|
|
endif
|
2016-02-12 20:20:24 +01:00
|
|
|
|
|
|
|
|
ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY),y)
|
|
|
|
|
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER
|
2016-04-25 22:53:11 +02:00
|
|
|
$(Q)$(call MESSAGE,"Copying gdbserver")
|
2016-02-12 20:20:24 +01:00
|
|
|
$(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 ; \
|
2012-03-14 23:49:57 +01:00
|
|
|
fi ; \
|
2016-02-12 20:20:24 +01:00
|
|
|
done ; \
|
|
|
|
|
if [ $${gdbserver_found} -eq 0 ] ; then \
|
|
|
|
|
echo "Could not find gdbserver in external toolchain" ; \
|
|
|
|
|
exit 1 ; \
|
2013-10-08 20:17:03 +02:00
|
|
|
fi
|
|
|
|
|
endef
|
2016-02-12 20:20:24 +01:00
|
|
|
endif
|
2011-04-29 13:09:26 +02:00
|
|
|
|
2014-12-01 22:41:37 +01:00
|
|
|
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 ; \
|
2016-10-27 17:33:42 +02:00
|
|
|
if [ "$${SYSROOT_DIR}" == "$${ARCH_SYSROOT_DIR}" ] ; then \
|
|
|
|
|
ARCH_SUBDIR="" ; \
|
|
|
|
|
elif [ "`dirname $${ARCH_SYSROOT_DIR}`" = "`dirname $${SYSROOT_DIR}`" ] ; then \
|
|
|
|
|
SYSROOT_DIR_DIRNAME=`dirname $${SYSROOT_DIR}`/ ; \
|
|
|
|
|
ARCH_SUBDIR=`echo $${ARCH_SYSROOT_DIR} | sed -r -e "s:^$${SYSROOT_DIR_DIRNAME}(.*)/$$:\1:"` ; \
|
|
|
|
|
else \
|
|
|
|
|
ARCH_SUBDIR=`echo $${ARCH_SYSROOT_DIR} | sed -r -e "s:^$${SYSROOT_DIR}(.*)/$$:\1:"` ; \
|
|
|
|
|
fi ; \
|
2014-12-01 22:41:37 +01:00
|
|
|
$(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
|
|
|
|
|
|
2013-06-08 11:14:22 +02:00
|
|
|
# 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.
|
2013-10-08 20:17:03 +02:00
|
|
|
ifeq ($(BR2_BFIN_INSTALL_FDPIC_SHARED),y)
|
2016-02-12 20:20:22 +01:00
|
|
|
define TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS_BFIN_FDPIC
|
2016-04-25 22:53:11 +02:00
|
|
|
$(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 ; \
|
2016-02-12 20:20:22 +01:00
|
|
|
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
|
2016-04-25 22:12:43 +02:00
|
|
|
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FDPIC
|
2016-04-25 22:53:11 +02:00
|
|
|
$(Q)$(call MESSAGE,"Install external toolchain FDPIC libraries to target...")
|
|
|
|
|
$(Q)for libs in $(TOOLCHAIN_EXTERNAL_LIBS); do \
|
2016-02-12 20:20:25 +01:00
|
|
|
$(call copy_toolchain_lib_root,$$libs); \
|
2013-10-08 20:17:03 +02:00
|
|
|
done
|
|
|
|
|
endef
|
|
|
|
|
endif
|
2013-06-08 11:14:22 +02:00
|
|
|
|
|
|
|
|
# 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.
|
2013-10-08 20:17:03 +02:00
|
|
|
ifeq ($(BR2_BFIN_INSTALL_FLAT_SHARED),y)
|
2016-04-25 22:12:43 +02:00
|
|
|
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FLAT
|
2016-04-25 22:53:11 +02:00
|
|
|
$(Q)$(call MESSAGE,"Install external toolchain FLAT libraries to target...")
|
|
|
|
|
$(Q)FLAT_EXTERNAL_CC=$(dir $(TOOLCHAIN_EXTERNAL_CC))../../bfin-uclinux/bin/bfin-uclinux-gcc ; \
|
2013-06-08 11:14:22 +02:00
|
|
|
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; \
|
2013-10-08 20:17:03 +02:00
|
|
|
fi
|
|
|
|
|
endef
|
2013-06-08 11:14:22 +02:00
|
|
|
endif
|
|
|
|
|
|
2016-07-04 14:26:35 +02:00
|
|
|
# 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.
|
2015-09-12 01:24:20 +02:00
|
|
|
# The LTO support in gcc creates wrappers for ar, ranlib and nm which load
|
|
|
|
|
# the lto plugin. These wrappers are called *-gcc-ar, *-gcc-ranlib, and
|
|
|
|
|
# *-gcc-nm and should be used instead of the real programs when -flto is
|
|
|
|
|
# used. However, we should not add the toolchain wrapper for them, and they
|
|
|
|
|
# match the *cc-* pattern. Therefore, an additional case is added for *-ar,
|
|
|
|
|
# *-ranlib and *-nm.
|
2013-10-08 20:17:03 +02:00
|
|
|
define TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER
|
2015-09-11 22:57:58 +02:00
|
|
|
$(Q)cd $(HOST_DIR)/usr/bin; \
|
2011-04-29 13:09:26 +02:00
|
|
|
for i in $(TOOLCHAIN_EXTERNAL_CROSS)*; do \
|
2011-11-01 01:53:38 +01:00
|
|
|
base=$${i##*/}; \
|
|
|
|
|
case "$$base" in \
|
2015-03-06 13:34:06 +01:00
|
|
|
*-ar|*-ranlib|*-nm) \
|
|
|
|
|
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%../..%') .; \
|
|
|
|
|
;; \
|
2016-07-04 14:26:35 +02:00
|
|
|
*cc|*cc-*|*++|*++-*|*cpp|*-gfortran) \
|
2015-10-04 14:28:41 +02:00
|
|
|
ln -sf toolchain-wrapper $$base; \
|
2011-04-29 13:09:26 +02:00
|
|
|
;; \
|
2013-07-30 18:32:30 +02:00
|
|
|
*gdb|*gdbtui) \
|
|
|
|
|
if test "$(BR2_PACKAGE_HOST_GDB)" != "y"; then \
|
|
|
|
|
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%../..%') .; \
|
|
|
|
|
fi \
|
|
|
|
|
;; \
|
2011-04-29 13:09:26 +02:00
|
|
|
*) \
|
2012-07-15 03:12:05 +02:00
|
|
|
ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%../..%') .; \
|
2011-04-29 13:09:26 +02:00
|
|
|
;; \
|
|
|
|
|
esac; \
|
2015-09-11 22:57:58 +02:00
|
|
|
done
|
2013-10-08 20:17:03 +02:00
|
|
|
endef
|
2011-07-13 08:49:52 +02:00
|
|
|
|
2015-09-11 22:57:58 +02:00
|
|
|
#
|
|
|
|
|
# Generate gdbinit file for use with Buildroot
|
|
|
|
|
#
|
2014-05-05 11:25:50 +02:00
|
|
|
define TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT
|
2015-09-11 22:57:58 +02:00
|
|
|
$(Q)if test -f $(TARGET_CROSS)gdb ; then \
|
|
|
|
|
$(call MESSAGE,"Installing gdbinit"); \
|
|
|
|
|
$(gen_gdbinit_file); \
|
2014-05-05 11:25:50 +02:00
|
|
|
fi
|
|
|
|
|
endef
|
|
|
|
|
|
2015-07-13 12:56:14 +02:00
|
|
|
# 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
|
2015-09-11 22:57:58 +02:00
|
|
|
$(Q)if test -e $(TARGET_DIR)/lib/ld-uClibc.so.1; then \
|
2015-07-13 12:56:14 +02:00
|
|
|
ln -sf ld-uClibc.so.1 $(TARGET_DIR)/lib/ld-uClibc.so.0 ; \
|
|
|
|
|
fi
|
2015-09-11 22:57:58 +02:00
|
|
|
$(Q)if test -e $(TARGET_DIR)/lib/ld64-uClibc.so.1; then \
|
2015-07-16 10:25:34 +02:00
|
|
|
ln -sf ld64-uClibc.so.1 $(TARGET_DIR)/lib/ld64-uClibc.so.0 ; \
|
|
|
|
|
fi
|
2015-07-13 12:56:14 +02:00
|
|
|
endef
|
|
|
|
|
|
2016-09-28 10:00:56 +02:00
|
|
|
TOOLCHAIN_EXTERNAL_BUILD_CMDS = $(TOOLCHAIN_WRAPPER_BUILD)
|
2015-10-04 14:28:41 +02:00
|
|
|
|
2014-12-01 22:41:37 +01:00
|
|
|
define TOOLCHAIN_EXTERNAL_INSTALL_STAGING_CMDS
|
2016-09-28 10:00:56 +02:00
|
|
|
$(TOOLCHAIN_WRAPPER_INSTALL)
|
2016-01-28 13:32:46 +01:00
|
|
|
$(TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK)
|
2014-12-01 22:41:37 +01:00
|
|
|
$(TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS)
|
2016-02-12 20:20:22 +01:00
|
|
|
$(TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS_BFIN_FDPIC)
|
2014-12-01 22:41:37 +01:00
|
|
|
$(TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER)
|
|
|
|
|
$(TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT)
|
|
|
|
|
endef
|
|
|
|
|
|
2013-10-08 20:17:03 +02:00
|
|
|
# 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.
|
2014-12-01 22:41:37 +01:00
|
|
|
define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_CMDS
|
2016-01-28 13:32:46 +01:00
|
|
|
$(TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK)
|
2014-12-01 22:41:37 +01:00
|
|
|
$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS)
|
2016-02-12 20:20:24 +01:00
|
|
|
$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER)
|
2016-04-25 22:12:43 +02:00
|
|
|
$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FDPIC)
|
|
|
|
|
$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FLAT)
|
2015-07-13 12:56:14 +02:00
|
|
|
$(TOOLCHAIN_EXTERNAL_FIXUP_UCLIBCNG_LDSO)
|
2013-10-08 20:17:03 +02:00
|
|
|
endef
|
2011-07-13 08:49:52 +02:00
|
|
|
|
2013-10-08 20:17:03 +02:00
|
|
|
$(eval $(generic-package))
|
2016-02-12 20:20:22 +01:00
|
|
|
|
