This commit wires-up the toolchain-external-bootlin package into
Buildroot by:
- Adding
toolchain/toolchain-external/toolchain-external-bootlin/Config.in,
which is not generated by the bl-toolchains-gen script as it is a
static file that does not depend on the list and characteristics of
available Bootlin toolchains.
- Including that file, as well as the Config.in.options file, from
toolchain/toolchain-external/Config.in.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Titouan Christophe <titouan.christophe@railnova.eu>
Tested-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit adds the contents of the
toolchain/toolchain-external/toolchain-external-bootlin/ files
generated by bl-toolchains-gen, unmodified.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This toolchain uses an old gcc 6.2.0 compiler (not even the latest gcc
from the 6.x series), which fails to build the recent Boost
package. Since newer versions of this toolchain are no longer made
publicly available from Mentor Graphics, our only option is to drop
the toolchain.
Fixes:
http://autobuild.buildroot.net/results/10edaed22c15b9d0f7de187085aeebc96e5ebe6c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This reverts commit bd9810e176. Indeed,
while uClibc-ng has support for RISC-V 64-bit, this support lacks the
__riscv_flush_icache() function call, which is used by some GCC
builtins used for example in libffi.
Due to this missing __riscv_flush_icache(), anything that links
against libffi fails to build:
/home/test/autobuild/run/instance-0/output-1/host/bin/riscv64-buildroot-linux-uclibc-gcc -o gobject/gobject-query gobject/gobject-query.p/gobject-query.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--start-group glib/libglib-2.0.so.0.6400.4 gobject/libgobject-2.0.so.0.6400.4 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../glib:$ORIGIN/' -Wl,-rpath-link,/home/test/autobuild/run/instance-0/output-1/build/libglib2-2.64.4/build/glib -Wl,-rpath-link,/home/test/autobuild/run/instance-0/output-1/build/libglib2-2.64.4/build/gobject
/home/test/autobuild/run/instance-0/output-1/host/lib/gcc/riscv64-buildroot-linux-uclibc/9.3.0/../../../../riscv64-buildroot-linux-uclibc/bin/ld: /home/test/autobuild/run/instance-0/output-1/host/riscv64-buildroot-linux-uclibc/sysroot/usr/lib64/libffi.so.7: undefined reference to `__riscv_flush_icache'
collect2: error: ld returned 1 exit status
Note that this commit means that
support/config-fragments/autobuild/br-riscv64-full-internal.config
will be back to using glibc as the C library, but that is OK, until
uClibc-ng is fixed to implemented __riscv_flush_icache().
This uClibc-ng issue has been reported upstream at
https://mailman.uclibc-ng.org/pipermail/devel/2020-August/002022.html.
Fixes:
http://autobuild.buildroot.net/results/ec1185ad1fd8863a3990143a0af2ace987761a27/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
We can enable uclibc for RISC-V 64 bit now that it has been
bumped from v1.0.32 to v1.0.34.
Uclibc has had basic support for RISC-V 64 bit since v1.0.31, but
shared library and TLS/NPTL support has only been available since
v1.0.33.
This update has been tested using qemu_riscv64_virt_defconfig and
the Buildroot host QEMU.
Signed-off-by: Mark Corbin <mark@dibsco.co.uk>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
For glibc 2.31.x:
- Update LICENSES file hash due to url change:
"Prefer https to http for gnu.org and fsf.org URLs"
- riscv64 does not build with kernel headers < 5.0, but upstream
has not yet comitted a single fix, neither in master nor in the
maintenance branch:
https://sourceware.org/ml/libc-alpha/2020-02/msg00018.html
For localedef 2.31.x:
- Remove upstream patch for localedef:
0003-localedef-Use-initializer-for-flexible-array-member-.patch
Note that this version bump required some patches applied on
several packages (already applied):
[Busybox] 13f2d688a2
[openssh] bad75bca31
[gcc] disable libsanitizer with gcc 7.5
See:
https://sourceware.org/legacy-ml/libc-announce/2020/msg00001.html
Tested by toolchain builder:
https://gitlab.com/kubu93/toolchains-builder/pipelines/129551000
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When using precompiled headers, changing any macros defined on the
command line will invalidate the precompiled header. With
toolchain-wrapper adding __DATE__ and __TIME__, any commits to Buildroot
will invalidate incremental builds regardless of whether the precompiled
header actually uses those values (affecting _OVERRIDE_SRCDIR).
GCC-7 and later support SOURCE_DATE_EPOCH and use it to define __DATE__
and __TIME__ internally, avoiding any impact on precompiled headers.
Disable the custom handling in toolchain-wrapper if GCC is version 7 or
newer.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch allows to use custom external toolchains based on gcc 10.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In order to add gcc 10 support for internal and external toolchain in
follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_10 symbol.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
On some legacy systems, the X11 headers and libs are in /usr/X11R66/include
and /usr/X11R66/lib, and of course, some packages are trying to be smart
and use those paths (even when they do not exist).
Add those to the list of unsafe paths to check in the toolchain wrapper.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
A gcc compiler, which was configured with
--with-gcc-major-version-only, will only return a single
number. (debian does this for example).
A simple modification allows the check to work with both
single numbers (eg. '9') and full versions (eg. '9.2.1').
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
From: Julien Boibessot <julien.boibessot@armadeus.com>
It could be usefull to have ldd on the target so install it.
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
[Sébastien: add commit message]
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Config option was placed at the wrong position.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
make-4.3 shipped with a backward incompatible change in how sharp signs
are handled in macros. Previously, up to make 4.2, the sharp sign would
always start a comment, unless backslash-escaped, even in a macro or a
fucntion call.
Now, the sharp sign is no longer starting a comment when it appears
inside such a macro or function call. This behaviour was supposed to be
in force since 3.81, but was not; 4.3 fixed the code to match the doc.
As such, use of external toolchains is broken, as we use the sharp sign
in the copy_toolchain_sysroot macro, in shell variable expansion to
strip off any leading /: ${target\#/}.
Fix that by applying the workaround suggested in the release annoucement
[0], by using a variable to hold a sharp sign.
[0] https://lists.gnu.org/archive/html/info-gnu/2020-01/msg00004.html
Signed-off-by: Yaroslav Syrytsia <me@ys.lc>
[yann.morin.1998@free.fr:
- move the SHARP_SIGN definition out of Makefile and into support/
- expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
[yann.morin.1998@free.fr:
- bump to 5.5.13
- rebase on top of master
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The external toolchain configure step calls the
check_kernel_headers_version make function to compare the kernel
headers version declared in the configuration with the actual kernel
headers of the toolchain.
This function takes 4 arguments, but due to a missing comma what
should be the first two arguments are both passed into the first
argument. Due to this, when check_kernel_headers_version does:
if ! support/scripts/check-kernel-headers.sh $(1) $(2) $(3) \
$(if $(BR2_TOOLCHAIN_HEADERS_LATEST),$(4),strict); \
Then:
$(1) contains "$(BUILD_DIR) $$(call toolchain_find_sysroot,$$(TOOLCHAIN_EXTERNAL_CC))"
$(2) contains "$$(call qstrip,$$(BR2_TOOLCHAIN_HEADERS_AT_LEAST))"
$(3) contains "$$(if $$(BR2_TOOLCHAIN_EXTERNAL_CUSTOM),loose,strict))"
So from the point of view of check-kernel-headers.sh, it already has
four arguments, and therefore the additional argument passed by:
$(if $(BR2_TOOLCHAIN_HEADERS_LATEST),$(4),strict); \
is ignored, defeating the $(BR2_TOOLCHAIN_HEADERS_LATEST) test.
The practical consequence is that a toolchain that has 5.4 kernel
headers but declared as using 5.3 kernel headers does not abort the
build, because the check is considered "loose" while it should be
"strict".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit adds a user-visible option
BR2_TOOLCHAIN_EXTERNAL_HAS_SSP_STRONG, which will allow the user to
indicate if the custom external toolchain does or does not have
SSP_STRONG support. Depending on this, the user will be able to use
(or not) the BR2_SSP_STRONG option.
Checking if what the user said is true or not about this is already
done in toolchain/toolchain-external/pkg-toolchain-external.mk:
$$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION))
If the user selects BR2_SSP_STRONG, this will check if
-fstack-protector-strong is really supported.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This will allow toolchain to indicate if they support
-fstack-protector-strong or not.
Whenever the gcc version is >= 4.9, we always have SSP_STRONG support
if we have SSP support. However, some toolchains older than gcc 4.9
might have backported SSP_STRONG support, which is why we cannot rely
just on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9.
Having this "default" value allows to avoid adding a "select
BR2_TOOLCHAIN_HAS_SSP_STRONG" in the internal toolchain logic plus in
almost external toolchains. But it allows custom external toolchains
that are pre-4.9 to potentially declare that they support strong SSP.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Most, but not all our C code follows the Linux kernel code style (as
documented in Documentation/process/coding-style.rst). Adjust the few
places doing differently:
- Braces:
..but the preferred way, as shown to us by the prophets Kernighan
and Ritchie, is to put the opening brace last on the line
- Spaces after keywords:
Use a space after (most) keywords
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When Buildroot is released, it knows up to a certain kernel header
version, and no later. However, it is possible that an external
toolchain will be used, that uses headers newer than the latest version
Buildroot knows about.
This may also happen when testing a development, an rc-class, or a newly
released kernel, either in an external toolchain, or with an internal
toolchain with custom headers (same-as-kernel, custom version, custom
git, custom tarball).
In the current state, Buildroot would refuse to use such toolchains,
because the test is for strict equality.
We'd like to make that situation possible, but we also want the user not
to be lenient at the same time, and select the right headers version
when it is known.
So, we add a new Kconfig blind option that the latest kernel headers
version selects. This options is then used to decide whether we do a
strict or loose check of the kernel headers.
Suggested-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
[yann.morin.1998@free.fr:
- only do a loose check for the latest version
- expand commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The oldest toolchain we test in the autobuilders is the Sourcery ARM
toolchain which is GCC 4.8 and kernel headers 3.13. Therefore, it is
likely that we're missing the required _AT_LEAST dependencies to exclude
packages that don't build with older GCC/headers.
Add a comment to the custom external toolchain that warns when an
untested GCC or kernel headers version is selected.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Lets update prebuilt ARC toolchain to the most recent arc-2019.09.
We are dropping dependency of BR2_ARCH_NEEDS_GCC_AT_LEAST_*
as for ARC arch there is no any selection of
BR2_ARCH_NEEDS_GCC_AT_LEAST_* option.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Many tools use __FILE__ or __BASE_FILE__ for debugging and both
capture the build path. This results in non-reproducible images when
building in different directories.
If the config uses GCC 8 or above, we use -ffile-prefix-map=old=new
and let gcc take care of the path remapping in __FILE__. Since GCC
versions before v8 did not have this feature, we use an empty string
in that case, and disable the builtin-macro-redefined warning which
would otherwise trigger and cause build issues with -Werror.
Signed-off-by: Atharva Lele <itsatharva@gmail.com>
[Thomas:
- as suggested by Arnout, use the empty string for the __FILE__ and
__BASE_FILE__ value
- as suggested by Romain, also handle __BASE_FILE__ in addition to
__FILE__
- pass -Wno-builtin-macro-redefined to avoid build errors when
-Werror is passed]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The current ARC glibc version in buildroot arc-2019.09-rc1 allows to
build an ARC big endian configuration, so let's allow this.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add an upstream URL to the help text in Config.in. This
addresses the 'Missing' URL status in the package stats
web page output.
[Peter: also add URL to BR2_TOOLCHAIN_BUILDROOT_MUSL help]
Signed-off-by: Mark Corbin <mark@dibsco.co.uk>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 6136765b23 ("toolchain:
generate check-headers program under $(BUILD_DIR)"), the
check_kernel_headers_version function was simplified to not check the
return value of the check-kernel-headers.sh script, assuming that
"make" does bail out on the first failing command.
However, check_kernel_headers_version when used in $(2)_CONFIGURE_CMDS
from pkg-toolchain-external.mk, is called in a sequence of commands,
where the return value of each command is not checked. Therefore, a
failure of check-kernel-headers.sh no longer aborts the build.
Since all other macros are using this principle of calling "exit 1",
we revert back to the same for check_kernel_headers_version, as it was
done prior to 6136765b23.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Carlos Santos <unixmania@gmail.com>
Reviewed-by: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
Currently, we set TOOLCHAIN_INSTALL_STAGING three times: once
(conditionally) in toolchain.mk, and once each (unconditionally) in
pkg-cmake.mk and pkg-meson.mk.
This is a little bit messy... Set it just once, unconditionally, in
toolchain.mk where it belongs.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
Build ID is added to binaries at link time. Building in different
output directories causes some packages to have different Build IDs,
thus resulting in non-reproducibility.
Adding "-Wl,--build-id=none" fixes this issue by disabling setting of
Build ID.
Diffoscope output for Build ID issue:
https://gitlab.com/snippets/1886180/raw
After this patch, build is reproducible - i.e. diffoscope does not
produce any output.
Signed-off-by: Atharva Lele <itsatharva@gmail.com>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since version 9.1, GCC provides support for the D programming language [1].
So add an option to indicate the selected toolchain supports this
language.
[1] https://dlang.org/
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
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>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Reviewed-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Tested-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.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>
