This patch extends the "copy extra GCC libraries to target" feature to
also work for internal toolchains. The variable has been renamed to be
BR2_TOOLCHAIN_EXTRA_LIBS and the configuration option moved under the
generic toolchain package. For external toolchains, the step that does
the copy is still in the copy_toolchain_lib_root() helper which copies
from the sysroot to the target. For the internal toolchain, the host
gcc-final package does a post install hook to copy the libraries from
the toolchain build folders to both the sysroot and target(!static).
Examples where this can be useful is for adding debug libraries to the
target like the GCC libsanitizer (libasan/liblsan/...).
Cc: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Commit 32bec8ee2f
("toolchain-external: copy ld*.so* for all C libraries") changed (among
other things) the glob pattern to catch the dynamic loader from
ld*.so.*
to
ld*.so*
thus now matching files like 'ld-2.20.so' in addition to files like
'ld.so.1'.
However, there is no apparent reason why that change was made. It is
not explicitly mentioned in the commit message as to why that would be
needed, nor is clear based on the rest of the changes in that
commit. But it turns out that it causes too many files to be copied
with some toolchains.
In most toolchains, the structure looks like this:
-rwxr-xr-x 1 tdescham tdescham 834364 Feb 16 21:23 output/target/lib/ld-2.16.so
lrwxrwxrwx 1 tdescham tdescham 10 Feb 16 21:23 output/target/lib/ld.so.1 -> ld-2.16.so
So, a symlink 'ld.so.1' which points to another file. Applications
would have 'ld.so.1' (the link) encoded as program interpreter
(readelf -l <program>, see INTERP entry)
The patterns like 'ld*.so*' are passed as argument to
copy_toolchain_lib_root which is defined in toolchain/helpers.mk.
This macro copy_toolchain_lib_root will find all files/links matching
the pattern. If a match is a regular file, it is simply copied. If it
is a symbolic link, the link is copied and then the logic is
recursively repeated on the link destination. That destination could
either again be a link or a regular file. In the first case we recurse
again, in the latter we stop and continue with the next match of the
pattern.
The problem this patch is solving is when a toolchain does not have
this structure with a link and a real file, but rather two actual
files:
-rwxr-xr-x 1 tdescham tdescham 170892 Feb 16 21:55 output/target/lib/ld-2.20.so
-rwxr-xr-x 1 tdescham tdescham 170892 Feb 16 21:55 output/target/lib/ld.so.1
In this case the pattern 'ld*.so*' would find two regular file matches
and copy both. On the other hand, the pattern 'ld*.so.*' would only
find the 'ld.so.1' file and copy just that. This saves about 170K in
rootfs size.
Closer inspection reveals that this particular toolchain has more such
dedoubled symbolic links, e.g. the standard pattern of
'usr/lib/libfoo.so -> libfoo.so.1 -> libfoo.so.1.0.2' is not present,
and each of these three components are real files. In any case, it is
obvious that the toolchain itself is 'broken'.
That being said, because we have the logic that recursively resolves
symbolic links, TOOLCHAIN_EXTERNAL_LIBS really only needs to contain
the "initial" name of the library to be copied.
Therefore, revert the glob pattern back to what it was.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Thomas: improve the commit log with the additional details from Thomas]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In Buildroot, the internal toolchain backend uses the SSP support from
the C library, not that of gcc.
Some external toolchains come with SSP suport in gcc, which is
implemented in libssp.so, rather than in the C library.
When a toolchain even has both, it is up to the compiler to decide
whether it will link to libssp or use the support from the C library.
However, in the latter case, a (incorrectly written) package may decide
to explicitly link with libssp.so when it is available (even though the
compiler may have decided otherwise if left by itself). This is the case
for example with sox, which results in runtime failures, such as:
$ sox
sox: error while loading shared libraries: libssp.so.0: cannot open
shared object file: No such file or directory
Even if sox is wrong in doing so, the case for libssp-only toolchains is
still valid, and we must copy it as we copy other libs.
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some installations mount /tmp with the 'noexec' option, which prevents
running the program generated there to check the kernel headers.
Avoid the problem by generating the program under $(BUILD_DIR), passed
as the first argument to check-kernel-headers.sh.
We could globally export a TMPDIR environment variable with some path
under $(BUILD_DIR) but such solution would be too intrusive, depriving
the user from the freedom to set TMPDIR at his will (or needs).
Fixes: https://bugs.busybox.net/show_bug.cgi?id=12241
Signed-off-by: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since we have a choice for the pre-configured pre-built toolchains,
there is no possbility for a br2-external to provide its own. The
only solution so far for defconfigs in br2-external trees is to use
BR2_TOOLCHAIN_EXTERNAL_CUSTOM and define all the bits by itself...
This is not so convemient, so offer a way for br2-external trees to
provide such pre-configured toolchains.
To allow for this, we now scan each br2-external tree and look for a
specific file, provides.toolchains.in. We generate a kconfig file that
sources each such file, and that generated file is sourced from within
the toolchain choice, thus making the toolchains from a br2-external
tree possible and available in the same location as the ones known to
Buildroot:
Toolchain --->
Toolchain type (External toolchain) --->
Toolchain --->
(X) Arm ARM 2019.03
( ) Linaro ARM 2018.05
( ) Custom toolchain
*** Toolchains from my-br2-ext-tree: ***
( ) My custom ARM toolchain
*** Toolchains from another-br2-ext-tree: ***
( ) Another custom ARM toolchain
( ) A third custom ARM toolchain
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some toolchain vendors may have backported those options to older gcc
versions, and we have no way to know, so we have to check that the
user's selection is acceptable.
Extend the macro that currently checks for SSP in the toolchain, with
a new test that the actual SSP option is recognised and accepted.
Note that the SSP option is either totaly empty, or an already-quoted
string, so we can safely and easily assign it to a shell variable to
test and use it.
Note that we do not introduce BR2_TOOLCHAIN_HAS_SSP_STRONG, because:
- our internal toolchain infra only supports gcc >= 4.9, so it has
SSP strong;
- of the external pre-built toolchains, only the codesourcery-arm
one has a gcc-4.8 which lacks SSP strong, all the others have a
gcc >= 4.9;
- we'd still have to do the actual check for custom external
toolchains anyway.
So, we're not adding BR2_TOOLCHAIN_HAS_SSP_STRONG just for a single
case.
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The custom external toolchain logic asks the user to specify which gcc
version is provided by the toolchain. The list of gcc versions given
by Buildroot is restricted depending on the selected CPU architecture
using the BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz config options.
However, these config options generally indicate in which upstream gcc
version the support for the selected architecture was introduced. But
in practice, it is possible that an external toolchain uses some
non-upstream gcc code, providing support for a CPU architecture before
it was merged in upstream gcc.
A specific example is that there are pre-built external toolchains for
the C-SKY CPU architecture that are based on gcc 6.x, even if the
support for it was only added in upstream gcc 9.x.
Due to the BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz options, only gcc >= 9.x
can be selected for C-SKY, preventing the use of such a custom
toolchain.
In addition, those dependencies are in fact not really needed:
Buildroot will check that the gcc version provided matches what the
user declared in the configuration. And if the gcc provided by the
toolchain does support that CPU architecture, then well, so be it,
there's no need to restrict the gcc version selected.
So we simply get rid of these dependencies on
BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz, and also don't use them anymore to
chose a default value for the gcc version.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 23c0e97b29 (toolchain-external: anchor sysroot regex with /)
tried to make the find-sysroot work more consistently, especially for
toolchains where the C library is located in a sub-directory, like the
"Realtek mips toolchain".
After that patch, the '/' that was trailing in the returned path got
removed now. This in turn breaks the Codesourcery toolchain.
We fix that by appending the now-missing trailing '/'.
Fixes:
http://autobuild.buildroot.net/results/9284d571668148febce23d96a9c0a97a6b2b43dc
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: 陈小 刚 <shawn_chen@realsil.com.cn>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Anchor the regex in toolchain_find_sysroot macro with a / to avoid
unexpected substitution for Realtek mips toolchain, for which the libc.a
path ends with 'mips-linux-uclibc/lib/libc.a'.
Signed-off-by: 陈小 刚 <shawn_chen@realsil.com.cn>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This patch allows to use an external toolchain based on gcc 9.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This external toolchain is pre-built for x86, so it can only work on
x86 and x86-64, and for the latter, the ia32 libraries are necessary.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds a new package for the Andes external toolchain for
the nds32 Little Endian architecture.
https://github.com/vincentzwc/prebuilt-nds32-toolchain/releases/download/20180521/nds32le-linux-glibc-v3-upstream.tar.gz
Signed-off-by: Che-Wei Chuang <cnoize@andestech.com>
Signed-off-by: Greentime Hu <greentime@andestech.com>
Signed-off-by: Nylon Chen <nylon7@andestech.com>
[Thomas:
- rename .mk and .hash files to carry the proper package name
- fix <pkg>_SITE variable, which was incorrect
- add prompt in Config.in
- add missing include of Config.in in toolchain/toolchain-external/Config.in
- add missing selects for RPC and SSP, since the toolchain supports
both
- drop BR2_TOOLCHAIN_EXTERNAL_URL option, the toolchain URL is
provided by the .mk file]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a new option for custom external toolchains to enable OpenMP
support.
Signed-off-by: Ed Blake <ed.blake@sondrel.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Enable OpenMP support in the following external toolchains:
toolchain-external-arm-aarch64-be
toolchain-external-arm-aarch64
toolchain-external-arm-arm
toolchain-external-codescape-img-mips
toolchain-external-codescape-mti-mips
toolchain-external-codesourcery-amd64
toolchain-external-codesourcery-mips
toolchain-external-linaro-aarch64-be
toolchain-external-linaro-aarch64
toolchain-external-linaro-arm
toolchain-external-linaro-armeb
Signed-off-by: Ed Blake <ed.blake@sondrel.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add new BR2_TOOLCHAIN_HAS_OPENMP option for toolchains with OpenMP
support.
Signed-off-by: Ed Blake <ed.blake@sondrel.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>From [1]:
* All GCC 8.2 features. For details on GCC 8 release series.
* Linaro specific pre-processor macros to ensure that this is a
continuation from the Linaro releases.
* Spectre v1 mitigation backport from upstream FSF trunk include the
revisions. This is an initial backport of those mitigations in
the GNU toolchain and should be regarded as support for prototyping
and early access only. Moreover, while the backports include support
for the other architectures, they are included for completeness and
all issues regarding these patches must be taken up upstream in the
https://gcc.gnu.org/bugzilla by reproducing the same with upstream
FSF trunk.
Arm is interested in feedback regarding these workarounds for
Spectre v1.
A description of the mitigation has been published on LWN.net.
See "Release Note":
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads#
Tested with qemu_aarch64_virt_defconfig.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
>From [1]:
* All GCC 8.2 features. For details on GCC 8 release series.
* Linaro specific pre-processor macros to ensure that this is a
continuation from the Linaro releases.
* Spectre v1 mitigation backport from upstream FSF trunk include the
revisions. This is an initial backport of those mitigations in
the GNU toolchain and should be regarded as support for prototyping
and early access only. Moreover, while the backports include support
for the other architectures, they are included for completeness and
all issues regarding these patches must be taken up upstream in the
https://gcc.gnu.org/bugzilla by reproducing the same with upstream
FSF trunk.
Arm is interested in feedback regarding these workarounds for
Spectre v1.
A description of the mitigation has been published on LWN.net.
See "Release Note":
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads#
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
>From [1]:
* All GCC 8.2 features. For details on GCC 8 release series.
* Linaro specific pre-processor macros to ensure that this is a
continuation from the Linaro releases.
* Spectre v1 mitigation backport from upstream FSF trunk include the
revisions. This is an initial backport of those mitigations in
the GNU toolchain and should be regarded as support for prototyping
and early access only. Moreover, while the backports include support
for the other architectures, they are included for completeness and
all issues regarding these patches must be taken up upstream in the
https://gcc.gnu.org/bugzilla by reproducing the same with upstream
FSF trunk.
Arm is interested in feedback regarding these workarounds for
Spectre v1.
A description of the mitigation has been published on LWN.net.
See "Release Note":
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads#
Tested with qemu_arm_vexpress_defconfig.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The 2016.05-06 toolchain we've had support for is pretty outdated at
this point, so update to the latest 2018.09-02 version.
Of note besides the typical component version bumps:
- The toolchains are now provided by MIPS Tech LLC after its departure
from Imagination Technologies.
- The download site changed as a result of that.
- The toolchains are now built targeting CentOS 6 rather than CentOS 5.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The 2016.05-06 toolchain we've had support for is pretty outdated at
this point, so update to the latest 2018.09-02 version.
Of note besides the typical component version bumps:
- The toolchains are now provided by MIPS Tech LLC after its departure
from Imagination Technologies.
- The download site changed as a result of that.
- The toolchains are now built targeting CentOS 6 rather than CentOS 5.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Lets update prebuilt ARC toolchain to the most recent arc-2018.09.
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
If a custom external toolchain is used, we can't enable the fortran
support. Add a new option for that.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is the same toolchain that was previously distributed by Linaro. [1]
Switch default toolchain as this toolchain supersed the Linaro AArch64-BE toolchain.
Only x86_64 host are supported, so keep Linaro toolchain for x86 host.
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is the same toolchain that was previously distributed by Linaro. [1]
Switch default toolchain as this toolchain supersed the Linaro AArch64 toolchain.
Only x86_64 host are supported, so keep Linaro toolchain for x86 host.
Tested with qemu_aarch64_virt_defconfig.
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is the same toolchain that was previously distributed by Linaro. [1]
Switch default toolchain as this toolchain supersed the Linaro ARM toolchain.
Only x86_64 host are supported, so keep Linaro toolchain for x86 host.
Tested with qemu_arm_vexpress_defconfig.
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
commit e0d14fb21b (toolchain-external: drop no longer needed
CC_TARGET_<foo>_ variables) dropped the CC_TARGET_* variables, but missed
one. Fix that.
Reported-by: Mark Corbin <mark.corbin@embecosm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the introduction of the GCC_TARGET_<foo> variables in
arch/arch.mk in commit bd0640a213
("arch: allow GCC target options to be optionally overwritten") and
the removal of the BR2_GCC_TARGET_CPU_REVISION, the CC_TARGET_<foo>_
variables in pkg-toolchain-external.mk map 1:1 with the corresponding
GCC_TARGET_<foo> variables.
So let's drop the CC_TARGET_<foo>_ variables, and use directly the
GCC_TARGET_<foo> ones.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 325bb37942, support for the
Blackfin architecture was removed. This was our only use of
BR2_GCC_TARGET_CPU_REVISION, and since this config option somewhat
complicates the calculation of the --with-cpu/-mcpu option values,
let's drop it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The BR2_GCC_TARGET_* configuration variables are copied to
corresponding GCC_TARGET_* variables which may then be optionally
modified or overwritten by architecture specific makefiles.
All makefiles must use the new GCC_TARGET_* variables instead
of the BR2_GCC_TARGET_* versions.
Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
[Thomas: simplify include of arch/arch.mk]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The check_musl function currently builds a program and verifies if the
program interpreter starts with /lib/ld-musl. While this works fine
for dynamically linked programs, this obviously doesn't work for a
purely static musl toolchain such as [1].
There is no easy way to identify a toolchain as using the musl C
library. For glibc, dynamic linking is always supported, so we look at
the dynamic linker name. For uClibc, there is a distinctive
uClibc_config.h header file. There is no such distinctive feature in
musl.
We end up resorting to looking for the string MUSL_LOCPATH, which is
used by musl locale_map.c source file. This string has been present in
musl since 2014. It certainly isn't a very stable or convincing
solution to identify the C library as being musl, but it's the best we
could find.
Note that we are sure there is a libc.a file, because the
check_unusable_toolchain function checks that there is a such a file.
[1] http://autobuild.buildroot.net/toolchains/tarballs/br-arm-musl-static-2018.05.tar.bz2
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
