path: root/toolchain
Commit message (Collapse)AuthorAgeFilesLines
* toolchain/toolchain-buildroot: enable uclibc for riscv64Gravatar Mark Corbin10 days1-6/+7
| | | | | | | | | | | | | | | 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>
* package/{glibc, localedef}: bump to version 2.31Gravatar Romain Naour11 days1-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] 13f2d688a24f47446af236829bd6ca194d5aea5b [openssh] bad75bca315dbd2c69f8a9cb02fa9f27636e3d48 [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>
* toolchain/toolchain-wrapper: let recent GCC handle SOURCE_DATE_EPOCHGravatar John Keeping2020-06-272-0/+13
| | | | | | | | | | | | | | | | | 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>
* toolchain/toolchain-external/toolchain-external-custom: add gcc 10 version ↵Gravatar Romain Naour2020-06-241-0/+4
| | | | | | | | | selection 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>
* toolchain/Config.in: add BR2_TOOLCHAIN_GCC_AT_LEAST_10 blind optionGravatar Romain Naour2020-06-241-0/+5
| | | | | | | | 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>
* toolchain/toolchain-wrapper.c: extend the list of unsafe pathsGravatar Yann E. MORIN2020-06-221-0/+2
| | | | | | | | | | | 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>
* toolchain: adjust version check to allow for single numbersGravatar Norbert Lange2020-06-141-1/+1
| | | | | | | | | | | | | 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>
* {linux, linux-headers}: add version 5.7Gravatar Michael Walle2020-06-052-1/+10
| | | | | Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
* toolchain/toolchain-external: install ldd on the targetGravatar Julien Boibessot2020-04-271-0/+7
| | | | | | | | | | | 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>
* toolchain/toolchain-buildroot: PPC64(LE) support in musl requires ALTIVECGravatar Vincent Fazio2020-04-201-0/+1
| | | | | | | | | | | | | | | | | | | | musl currently assumes all PPC64(LE) CPUs support ALTIVEC instructions. However, there are exceptions (such as the e5500) for which musl builds ultimately generate illegal instructions for the targets. Disable musl if the PPC64(LE) CPU does not support ALTIVEC instructions. This patch addresses the issues seen here: https://gitlab.com/kubu93/toolchains-builder/-/jobs/418092743 https://gitlab.com/kubu93/toolchains-builder/-/jobs/418092744 musl mailing list thread: https://www.openwall.com/lists/musl/2020/02/03/10 Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
* {linux, linux-headers}: add version 5.6Gravatar Bernd Kuhls2020-04-022-1/+10
| | | | | | Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> [Peter: move .. or later text to 5.6] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain/Config.in: move BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_5Gravatar Bernd Kuhls2020-04-021-4/+4
| | | | | | | 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>
* Makefile: make-4.3 now longer un-escapes \# in macrosGravatar Yaroslav Syrytsia2020-03-311-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* {linux, linux-headers}: add version 5.5Gravatar Jagan Teki2020-03-292-1/+10
| | | | | | | | | 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>
* toolchain/toolchain-external: fix call to check_kernel_headers_versionGravatar Thomas Petazzoni2020-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: introduce BR2_TOOLCHAIN_HAS_GCC_BUG_93847Gravatar Giulio Benetti2020-02-261-0/+7
| | | | | | | | | | | | git package fails to build for the Nios2 architecture with optimization enabled with gcc < 9.x: http://autobuild.buildroot.net/results/924/92484c49b655e4aa78ca52f124c6d8f605b9d06b/ It's been reported upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847 Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/external: fix SSP help texts for custom toolchainsGravatar Yann E. MORIN2020-02-201-2/+2
| | | | Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
* toolchain/toolchain-external/toolchain-external-custom: add option to ↵Gravatar Thomas Petazzoni2020-02-201-0/+12
| | | | | | | | | | | | | | | | | | | | | indicate SSP_STRONG support 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>
* toolchain: add hidden BR2_TOOLCHAIN_HAS_SSP_STRONG booleanGravatar Thomas Petazzoni2020-02-201-0/+4
| | | | | | | | | | | | | | | | | | 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>
* toolchain: use consistent code style for C codeGravatar Peter Korsgaard2020-02-081-1/+1
| | | | | | | | | | | | | | | | 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>
* toolchain: allow using custom headers newer than latest known onesGravatar Vincent Fazio2020-02-084-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain/toolchain-external: warn for untested GCC/kernel versionGravatar Arnout Vandecappelle (Essensium/Mind)2020-02-021-0/+6
| | | | | | | | | | | | | 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>
* toolchain: bump ARC prebuild toolchain to arc-2019.09Gravatar Evgeniy Didin2020-01-183-9/+8
| | | | | | | | | | | | | | 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>
* toolchain-external: update Arm AArch64 BE toolchain 9.2-2019.12Gravatar Romain Naour2020-01-084-10/+10
| | | | | | | | | | | | | Update to gcc 9.2.1, gdb 8.3.0, binutils 2.33.1. The download url has been fixed: https://bugs.linaro.org/show_bug.cgi?id=5529 See "Release Note": 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>
* toolchain/toolchain-wrapper: handle __{BASE_,}FILE__ macro for reproducibilityGravatar Atharva Lele2020-01-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain/toolchain-external: update Arm AArch64 toolchain 9.2-2019.12Gravatar Romain Naour2020-01-044-10/+10
| | | | | | | | | | | | Update to gcc 9.2.1, gdb 8.3.0, binutils 2.33.1. See "Release Note": 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: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/toolchain-external: update Arm ARM toolchain 9.2-2019.12Gravatar Romain Naour2020-01-044-12/+12
| | | | | | | | | | | | Update to gcc 9.2.1, gdb 8.3.0, binutils 2.33.1. See "Release Note": 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: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/toolchain-buildroot: allow ARC big endian glibc buildsGravatar Vineet Gupta2019-12-061-1/+1
| | | | | | | | 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>
* {linux, linux-headers}: add version 5.4Gravatar Marcus Folkesson2019-12-022-0/+9
| | | | | Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* package/musl: add an upstream URL to Config.inGravatar Mark Corbin2019-11-291-0/+2
| | | | | | | | | | 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>
* toolchain/helpers: make sure we bail out when kernel headers check failsGravatar Thomas Petazzoni2019-11-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | In commit 6136765b23abd9faba610dd54ed276a777811575 ("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 6136765b23abd9faba610dd54ed276a777811575. 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>
* toolchain/toolchain-external: add a check for D language supportGravatar Eric Le Bihan2019-11-042-1/+23
| | | | | Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: expose BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS for all toolchain typesGravatar Matt Weber2019-10-283-9/+15
| | | | | | | | | | | | | | | | | | 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>
* toolchain/toolchain: set TOOLCHAIN_INSTALL_STAGING only onceGravatar Arnout Vandecappelle (Essensium/Mind)2019-10-271-1/+1
| | | | | | | | | | | | 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>
* toolchain/toolchain-external: restrict copying of dynamic loader to ld*.so.*Gravatar Thomas De Schampheleire2019-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 32bec8ee2fb00c6750fa842bbb0eb79b0c081fa2 ("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>
* toolchain/toolchain-wrapper: explicitly pass --build-id=none if BR2_REPRODUCIBLEGravatar Atharva Lele2019-10-261-0/+4
| | | | | | | | | | | | | | | | | | | 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>
* toolchain/toolchain-external: add support for D languageGravatar Eric Le Bihan2019-10-252-0/+11
| | | | | Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: add support for D languageGravatar Eric Le Bihan2019-10-251-0/+3
| | | | | | | | | | | | 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>
* toolchain/external: copy libssp.so if SSP is enabledGravatar Yann Droneaud2019-10-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* {linux, linux-headers}: bump to version 5.3.1Gravatar James Hilliard2019-09-282-0/+9
| | | | | Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: generate check-headers program under $(BUILD_DIR)Gravatar Carlos Santos2019-09-252-5/+5
| | | | | | | | | | | | | | | | | 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>
* toolchain/wrapper: also dump args it was called withGravatar Yann E. MORIN2019-08-181-20/+29
| | | | | | | | | 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>
* core: allow br2-external trees to provide pre-configured toolchainsGravatar Yann E. MORIN2019-08-041-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: allow PIC/PIE without RELROGravatar Yann E. MORIN2019-08-032-1/+5
| | | | | | | | | | | | | | | | | | | | | In commit 7484c1c3b806 (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>
* toolchain: check the SSP option is knownGravatar Yann E. MORIN2019-08-032-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain/toolchain-external/toolchain-external-custom: be more flexible on ↵Gravatar Thomas Petazzoni2019-08-031-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gcc version 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>
* toolchain-external: fix find_sysrootGravatar Yann E. MORIN2019-08-011-1/+1
| | | | | | | | | | | | | | | | | | | | Commit 23c0e97b29a (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>
* toolchain-external: anchor sysroot regex with /Gravatar 陈小 刚2019-08-011-1/+1
| | | | | | | | | 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>
* toolchain-buildroot: musl only supports 64bit variant of risc-vGravatar Peter Korsgaard2019-07-301-1/+1
| | | | | Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: enable musl for riscvGravatar Jörg Krause2019-07-301-1/+1
| | | | | | | | 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>