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>
In commit 7484c1c3b8 (toolchain/toolchain-wrapper: add BR2_RELRO_),
we added the PIC/PIE flags, but based on the RELRO_FULL condition.
It is however totally possible to do a PIC/PIE executable without
RELRO_FULL, as it is also valid to do a PIC/PIE build with RELRO_PARTIAL.
Add a new option that now governs the PIC/PIE flags.
Note: it is unknown if RELRO_FULL really needs PIC/PIE or not, so we
keep the current situation, where RELRO-FULL forces PIC/PIE compilation.
Decoupling can come later from an interested party.
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>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
Since version 1.1.23 musl supports the RISC-V architecture.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Tested-by: Mark Corbin <mark.corbin@embecosm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
In order to add gcc 9 support for internal and external toolchain in
follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_9 symbol.
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>
gcc bug 90620 appears with gcc 8.x so remove the version check
dependency and keep only the BR2_microblaze one.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
dmalloc and fxload fail to build for the Microblaze architecture with
optimization enabled with gcc < 8.x, with the following failure:
Error: PC relative branch to label logerror which is not in the instruction space
Error: operation combines symbols in different segments
The following defconfig allows to reproduce the issue:
BR2_microblazeel=y
BR2_OPTIMIZE_2=y
BR2_KERNEL_HEADERS_5_0=y
BR2_GCC_VERSION_7_X=y
BR2_PACKAGE_FXLOAD=y
The gcc bug was reported at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63261 and is fixed as of
gcc 8.x.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
GCC fails building the haproxy package for the Microblaze architecture:
http://autobuild.buildroot.org/results/64706f96db793777de9d3ec63b0a47d776cf33fd/
The gcc bug was originally reported gpsd:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90620
This gcc bug no longer appeared with gcc 8.x but reappeared in gcc
9.x, so we introduce a config symbol so that packages can work it
around by disabling optimization.
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>
Gcc bug 85180 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180) has
been fixed on Gcc version >= 8.x, so this commit adjusts the
BR2_TOOLCHAIN_HAS_GCC_BUG_85180 option to no longer be true when the
gcc version is >= 8.x.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.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>
Currently, we repeat all the SSP level selection deep down to the
toolchain wrapper itself, where we eventually translate it to the
actual SSP option to use. This is a bit redundant.
Additionally, we will want to check that the toolchain actually
supports that option (for those toolchain where it was backported).
So, move the translation into kconfig, and add the qstrip'ed value
to the additional flags passed to the wrapper. Add it before
user-supplied opitons, to keep the previous behaviour (and allow
anyone crazy-enough to override it with BR2_TARGET_OPTIMIZATION).
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>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, we pass the user-supplied so-called target optimisation flags
to the wrapper.
We're going to have additional such CFLAGS to pass, so push-back the
formatting loop to quote the options at the last moment.
Reported-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
GCC uses thunk functions to adjust the 'this' pointer when calling C++
member functions in classes derived with multiple inheritance.
Generation of thunk functions requires support from the compiler back
end. In the absence of that support target-independent code in the C++
front end is used to generate thunk functions, but it does not support
vararg functions.
Support for this feature is currently missing in or1k and xtensa
toolchains.
Add hidden option BR2_TOOLCHAIN_SUPPORTS_VARIADIC_MI_THUNK that
indicates presence of this feature in the toolchain. Add dependency to
packages that require this feature to be built.
Fixes:
http://autobuild.buildroot.net/results/c9e660c764edbd7cf0ae54ab0f0f412464721446/http://autobuild.buildroot.net/results/9a3bf4b411c418ea78d59e35d23ba865dd453890/
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
It is set when the platform exposes the struct ucontext_t.
This avoids duplication of logic inside each package requiring
the use of that type.
Signed-off-by: Patrick Havelange <patrick.havelange@essensium.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
