summaryrefslogtreecommitdiffstats
path: root/toolchain
Commit message (Collapse)AuthorAgeFilesLines
...
* arch/mips: add support for MIPS NaNVicente Olivert Riera2017-07-162-0/+8
| | | | | | | | | | | | | | | | | MIPS supports two different NaN encodings, legacy and 2008. Information about MIPS NaN encodings can be found here: https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html NaN legacy is the only option available for R2 cores and older. NaN 2008 is the only option available for R6 cores. R5 cores can have either NaN legacy or NaN 2008, depending on the implementation. So, if the user selects a generic R5 target architecture variant, we show a choice menu with both options available. For well known R5 cores we directly select the NaN enconding they use. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: default BR2_TOOLCHAIN_EXTERNAL_PATH to emptyArnout Vandecappelle2017-07-101-2/+6
| | | | | | | | | | | | It makes no sense to default to an arbitrary path. In addition, it in fact works correctly when it is empty. In that case, the toolchain will be searched in PATH. Update the help text to explain the above, and also that the compiler is supposed to be in the bin subdirectory. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-wrapper: remove remaining references to HOST_DIR/usrArnout Vandecappelle2017-07-101-2/+2
| | | | | | | | | | | Commit 14151d77af20ec50eeba6e30465debf87b35faaa that eliminated $(HOST_DIR)/usr seriously missed the toolchain-wrapper - only a single reference was updated, the other three were missed. Commit 015d68c84c9c6ad6f6d41f181d19d813f309088b removed one more. This commit finally removes the two remaining ones. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: add 4.12.x choice for headersJoel Stanley2017-07-082-0/+9
| | | | | Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-wrapper: fix breakage after host/usr removalArnout Vandecappelle2017-07-071-1/+1
| | | | | | | | | | | | | | | | The toolchain wrapper, when called through PATH, strips the last three levels of /proc/self/exe to find HOST_DIR. However, after the host/usr removal, this should be just two levels. The toolchain wrapper has different logic for when it is called with a full path (i.e. $HOST_DIR/usr/bin/arm-linux-gcc) then when it is called through the PATH (i.e. just arm-linux-gcc). The latter is never used internally in Buildroot, that's why this wasn't discovered through testing. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Mark Jackson <mpfj-list@newflow.co.uk> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: drop reference to non-existing variableBaruch Siach2017-07-061-4/+0
| | | | | | | | | | Commit 32bec8ee2fb0 (toolchain-external: copy ld*.so* for all C libraries) removed the definition of TOOLCHAIN_EXTERNAL_MUSL_LD_LINK. Remove also the reference to it. Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: replace absolute symlinks by relative symlinks during sysroot copyThomas Petazzoni2017-07-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 32bec8ee2fb00c6750fa842bbb0eb79b0c081fa2 ("toolchain-external: copy ld*.so* for all C libraries") we changed how the musl dynamic linker symbolic link was being created. Instead of having specific logic in Buildroot, we switched to simply copying the ld*.so.* symbolic link from staging to target, as well as the target of this symbolic link. However, it turns out that by default, musl creates its dynamic linker symbolic link with an absolute path as the target of the link: /lib/libc.so. Therefore, external Musl toolchains built with Buildroot look like this: lrwxrwxrwx 1 thomas thomas 12 Jul 4 19:46 ld-musl-armhf.so.1 -> /lib/libc.so The principle of the copy_toolchain_lib_root function, which is used to copy libraries from staging to target, is to copy symbolic links and follow their targets. In this case, it means we end up copying /lib/libc.so (from the host machine) into the target folder. From there on, there are two cases: 1. /lib/libc.so exists in your host system. It gets copied to the target. But later on, Buildroot also copies /lib/libc.so from staging to target, overwriting the bogus libc.so. So everything works fine, even though it's admittedly ugly. 2. /lib/libc.so doesn't exist in your host system. In this case, the build fails with no clear error message. This problem does not happen with Musl toolchains built by Crosstool-NG, because Crosstool-NG replaces the absolute target of the dynamic linker symbolic link by a relative path. However, since we want to support existing Buildroot Musl toolchains and generally work with the fact that Musl by default installs an absolute symlink, the following commit improves the copy_toolchain_sysroot function to replace symbolic links with an absolute destination to use a relative destination. I.e, in staging, the ld-musl-armhf.so.1 symbolic link looks like this: lrwxrwxrwx 1 thomas thomas 14 Jul 5 22:59 output/staging/lib/ld-musl-armhf.so.1 -> ../lib/libc.so Fixes: http://autobuild.buildroot.net/results/ce80264575918a8f71d9eab1091c21df85b65b1a/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/helpers.mk: fix creation of DESTDIR in copy_toolchain_lib_rootArnout Vandecappelle2017-07-051-2/+1
| | | | | | | | | | | | | | | | | | In commit b3cc7e65ee, the definition of the DESTDIR variable was moved down into the loop that follows symlinks in the libraries that are copied to target. However, the corresponding mkdir was not moved down, so that no directories are ever created. In practice, this mkdir is normally redundant since the directories should already have been created as part of creating STAGING_DIR. Still, the current situation is clearly wrong, so fix it by moving the mkdir down to after the assignment to DESTDIR. While we're at it, also remove a redundant empty line. It's a leftover from when a lot of variables were declared above. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Globally replace $(HOST_DIR)/usr/bin with $(HOST_DIR)/binArnout Vandecappelle2017-07-052-5/+5
| | | | | | | | | | | Since things are no longer installed in $(HOST_DIR)/usr, the callers should also not refer to it. This is a mechanical change with git grep -l '$(HOST_DIR)/usr/bin' | xargs sed -i 's%$(HOST_DIR)/usr/bin%$(HOST_DIR)/bin%g' Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/helpers.mk: simplify ld.so fixup in copy_toolchain_sysrootThomas Petazzoni2017-07-051-4/+1
| | | | | | | | | | | | | | | | | In copy_toolchain_sysroot, if no ld.so has been found in the STAGING_DIR after the sysroot copy, we look at ARCH_SYSROOT_DIR if a ld.so is available there. We do this for both ld*.so and ld*.so.*. However, when copying thing from staging to target (as listed in TOOLCHAIN_EXTERNAL_LIBS), we only match on ld*.so.*. This would mean that even if a dynamic linker matching ld*.so but not ld*.so.* was copied into staging by copy_toolchain_sysroot, it would anyway not be copied to the target filesystem, making the system unusable. Therefore, we can remove the special case on ld*.so, and keep only ld*.so.*. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: also put libgcc_s.so unconditionally in ↵Thomas Petazzoni2017-07-051-3/+3
| | | | | | | | | | TOOLCHAIN_EXTERNAL_LIBS libgcc_s.so is now added to TOOLCHAIN_EXTERNAL_LIBS for glibc/uclibc in one place, and for musl in another place. Bottom line: it should be in TOOLCHAIN_EXTERNAL_LIBS unconditionally. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: copy ld*.so* for all C librariesThomas Petazzoni2017-07-051-29/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, for the dynamic loader, we're copying ld*.so* for glibc and uClibc, except for glibc/EABIhf where we are explicitly copying ld-linux-armhf.so.*. For musl, we're not copying the dynamic linker because it's simply a symbolic link to libc.so. However, the name of the musl dynamic linker changes from one architecture to the other, and we don't handle all cases. Since handling the musl dynamic linker symlink creation is becoming more and more annoying to maintain, this commit makes musl use the same mechanism as glibc/uClibc: put the dynamic linker in TOOLCHAIN_EXTERNAL_LIBS. In addition, the special condition on glibc/EABIhf was added in 11ec38b6950cf3337b52fb97f27c2fd7c776c5c2 ("toolchain-external: fix Linaro ARM toolchain support") because an old Linaro toolchain had two dynamic loaders, and we wanted to copy only one. But 1/ this is old and 2/ having the two dynamic linkers doesn't really matter. So this commit simply unconditionally adds "ld*.so*" to TOOLCHAIN_EXTERNAL_LIBS, regardless of the C library being chosen. It re-uses the musl dynamic linker symlink from the sysroot, which makes it always correct, and allows us to remove the TOOLCHAIN_EXTERNAL_MUSL_LD_LINK hook, and all the related logic. This commit therefore solves two problems with the musl dynamic linker symbolic link creation logic: 1 We support all architectures, without having to hardcode in Buildroot the mapping between the CPU architecture and the corresponding dynamic linker name. For example, our current logic was not handling the mips64+n32 ABI case, where the dynamic linker is named ld-musl-mipsn32el.so.1. 2 We support Crosstool-NG musl toolchains, where the dynamic linker is in /lib, but libc.so is in /usr/lib. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- This commit therefore replaces: - https://patchwork.ozlabs.org/patch/780411/ (was another solution for solving problem 1 above) - https://patchwork.ozlabs.org/patch/763977/ and https://patchwork.ozlabs.org/patch/748974/ (was another solution for solving problem 2 above)
* toolchain/helpers.mk: re-evaluate DESTDIR in copy_toolchain_lib_rootThomas Petazzoni2017-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | copy_toolchain_lib_root copies libraries from staging to target, resolving and copying symbolic links along the way. The most inner loop, a "while" loop, starts from an initial name, and if it's a symbolic link, gets resolved to the target, and the loop iterates until we reach a real file. However, the destination folder where the symbolic link or real file is created is computed in DESTDIR only once, before this loop starts. Therefore, this loop works fine when all symbolic links in the chain, and the real file all belong to the same directory. But it doesn't do the correct thing when the symbolic link and/or real file are in different folder. An example is Crosstool-NG musl toolchains, where the dynamic loader is in /lib/ld-musl*.so but points to ../usr/lib/libc.so. With the current logic, we copy /lib/ld-musl*.so to /lib, but we also copy libc.so to /lib instead of the expected /usr/lib. This currently doesn't cause any problem because the musl dynamic linker is manually created by the TOOLCHAIN_EXTERNAL_MUSL_LD_LINK hook. However, this logic has a number of problems, so in a followup commit, we are going to put the musl dynamic linker in TOOLCHAIN_EXTERNAL_LIBS, which will cause it to be copied by copy_toolchain_lib_root. But we obviously want the link and its target to be copied to the right place, hence this fix. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* pkg-cmake: move configuration files out of $(HOST_DIR)/usrArnout Vandecappelle2017-07-051-2/+2
| | | | | | | | | | | Move toolchainfile.cmake and Buildroot.cmake from $(HOST_DIR)/usr/share/buildroot to $(HOST_DIR)/share/buildroot. Build-tested with a bunch of cmake packages. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Eliminate $(HOST_DIR)/usrArnout Vandecappelle2017-07-052-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use $(HOST_DIR)/usr as the prefix for host packages. That has a few disadvantages: - There are some things installed in $(HOST_DIR)/etc and $(HOST_DIR)/sbin, which is inconsistent. - To pack a buildroot-built toolchain into a tarball for use as an external toolchain, you have to pack output/host/usr instead of the more obvious output/host. - Because of the above, the internal toolchain wrapper breaks which forces us to work around it (call the actual toolchain executable directly). This is OK for us, but when used in another build system, that's a problem. - Paths are four characters longer. To allow us to gradually eliminate $(HOST_DIR)/usr while building packages, replace it with a symlink to . The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and $(HOST_DIR)/usr/lib that were added previously are removed again. Note that the symlink creation will break when $(HOST_DIR)/usr already exists as a directory, i.e. when rebuilding in an existing output directory. This is necessary: if we don't break it now, the following commits (which remove the usr part from various variables) _will_ break it. At the same time as creating this symlink, we have to update the external toolchain wrapper and the external toolchain symlinks to go one directory less up. Indeed, $(HOST_DIR) is one level less up than it was before. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: drop BR2_NEEDS_GETTEXT{,_IF_LOCALE}Thomas Petazzoni2017-07-051-14/+0
| | | | | | | | | Now that all packages have been migrated to the new gettext logic, we can remove the BR2_NEEDS_GETTEXT and BR2_NEEDS_GETTEXT_IF_LOCALE variables. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain: introduce BR2_TOOLCHAIN_HAS_FULL_GETTEXTThomas Petazzoni2017-07-042-0/+7
| | | | | | | | | | | | | This new boolean is true if the toolchain provides a built-in full-featured implementation of gettext (glibc), and false if only a stub implementation is provided (uclibc, musl). This will be used in follow-up commits to decide whether libintl needs to be built by gettext or not. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: CodeSourcery AMD64 affected by PR19615Romain Naour2017-07-042-0/+6
| | | | | Signed-off-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: skip ld-musl symlink on static buildBaruch Siach2017-07-021-1/+1
| | | | | | | | | | Static build with external musl toolchain leaves a dangling symlink to libc.so. Don't create that symlink on static build. Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* glibc: remove version choiceWaldemar Brodkorb2017-06-241-2/+3
| | | | | | | | | | | | | We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library. No legacy handling required as only version choice is removed. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: move 3.2 kernel headers dependency to the libc choice in toolchain/toolchain-buildroot/Config.in file, and added a Config.in comment about it.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: update list of toolchainsBaruch Siach2017-06-201-2/+1
| | | | | | | | Remove mention of toolchains the we don't have. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: remove CodeSourcery sh toolchainBaruch Siach2017-06-205-56/+0
| | | | | | | | | | | | | | | | | | | | Since glibc 2.17, executable link command need not include the -lrt option for clock_* system calls. As a result, over time less and less software packages bother to check whether to toolchain needs -lrt. We are now at a point where maintainers refuse to add this complexity into their build system. This requires Buildroot to carry patches fixing this issue indefinitely. glibc 2.17 is now 4.5 years old. There is no reason to use an older version with current software. This commit removes the predefined profile for CodeSourcery sh toolchain that is based on glibc 2.16. One may still use the custom external toolchain support in Buildroot to get this toolchain back, and deal with any build issues that this toolchain causes. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: remove CodeSourcery x86 toolchainBaruch Siach2017-06-205-57/+2
| | | | | | | | | | | | | | | | | | | | Since glibc 2.17, executable link command need not include the -lrt option for clock_* system calls. As a result, over time less and less software packages bother to check whether to toolchain needs -lrt. We are now at a point where maintainers refuse to add this complexity into their build system. This requires Buildroot to carry patches fixing this issue indefinitely. glibc 2.17 is now 4.5 years old. There is no reason to use an older version with current software. This commit removes the predefined profile for CodeSourcery x86 toolchain that is based on glibc 2.16. One may still use the custom external toolchain support in Buildroot to get this toolchain back, and deal with any build issues that this toolchain causes. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/toolchain-common.in: adjust BR2_TOOLCHAIN_HAS_GCC_BUG_64735 for GCC 7Jörg Krause2017-06-061-0/+1
| | | | | | | | As GCC 7 is now available in Buildroot, update the definition for BR2_TOOLCHAIN_HAS_GCC_BUG_64735 as the bug #64735 is fixed in GCC 7. Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Merge branch 'next'Peter Korsgaard2017-06-012-0/+9
|\ | | | | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * package/gcc: add support for gcc 7Romain Naour2017-05-242-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove upstream patches: 831-ARM-PR-target-70473-Reduce-size-of-Cortex-A8-automat.patch 870-xtensa-Fix-PR-target-78118.patch 871-xtensa-Fix-PR-target-78603.patch 890-fix-m68k-compile.patch: https://github.com/gcc-mirror/gcc/commit/1701058da920d27de87dc82e8d327b8ca930e997 892-libgcc-mkmap-symver-support-skip_underscore.patch: https://github.com/gcc-mirror/gcc/commit/6c8f362e1f17cce05131eb8ff53963d64bc69484 893-libgcc-config-bfin-use-the-generic-linker-version-in.patch: https://github.com/gcc-mirror/gcc/commit/966d046c08ba50fc988ac614f84f2d49c1546e28 894-libgcc-fix-DWARF-compilation-with-FDPIC-targets.patch: https://github.com/gcc-mirror/gcc/commit/397d0e43abb943f1fe57801220e7e46bc6636c7c 895-bfin-define-REENTRANT.patch: https://github.com/gcc-mirror/gcc/commit/da89a4dcdf75bc3134f73520535c949bbbb0c845 940-uclinux-enable-threads.patch: https://github.com/gcc-mirror/gcc/commit/b9ce54109ec78d18f6123a1e54aae1293bede716 941-mips-Add-support-for-mips-r6-musl.patch: https://github.com/gcc-mirror/gcc/commit/83717065090bb8b954556d1216dd9dc397dc0243 Remove obsolete patches: 301-missing-execinfo_h.patch: boehm-gc removed from gcc sources: https://github.com/gcc-mirror/gcc/commit/baf71228766058f5541d929891237d394376c975 830-arm_unbreak_armv4t.patch: SUBTARGET_CPU_DEFAULT removed: https://github.com/gcc-mirror/gcc/commit/ff3caa3ade14a42d5ab7e81cbd3605fe15aa998d Add a new patch to allow to build gcc 7.1 without extracting gcc/testsuite directory. This new gcc version require a kernel patch [1] to avoid a build issue with ____ilog2_NaN symbol. The following kernel version contain contain already this patch : 4.11, 4.10.6, 4.9.18, 4.4.57, 3.18.50 and 3.12.73. To build a toolchain based on gcc 7 and uClibc-ng 1.0.24, the patch [2] is required to avoid a build issue due to missing aligned_alloc() definition. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=474c90156c8dcc2fa815e6716cc9394d7930cb9c [2] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/commit/?id=5b0f49037e8ea8500b05c8f31ee88529ccac4cee Signed-off-by: Romain Naour <romain.naour@gmail.com> Tested-by: Theodore Ateba <tf.ateba@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* | toolchain-external: adjust musl dynamic linker symlink for mips-sfThomas Petazzoni2017-05-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | The external toolchain code has some logic to calculate the correct name for the dynamic linker symbolic link that needs to be created when the musl C library is being used. There was already some handling for the mipsel+soft-float case, but not for the mips+soft-float case. Due to this, the symbolic link was incorrectly named, and programs were referencing an non-existing file. Reported-by: Florent Jacquet <florent.jacquet@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* | toolchain: disable PIE for static build with muslBaruch Siach2017-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mentioned in commit 3c93901bcd2 (toolchain: add hidden symbol for PIE support), support for static PIE using musl requires a gcc patch[1]. Buildroot doesn't carry this patch. Don't enable BR2_TOOLCHAIN_SUPPORTS_PIE in static build with musl. Fixes: http://autobuild.buildroot.net/results/d19/d19bcfcfb33cc5f5b082b97bbd5852d479823b97/ http://autobuild.buildroot.net/results/91f/91f7c6954c337b03f5ac141050d9b1bee1623376/ http://autobuild.buildroot.net/results/996/996116da9241686110b9525eed08cc5acfd379a6/ [1] https://github.com/richfelker/musl-cross-make/blob/b854a42fc1ea19b8c4ec7104848f9d1a6d7995f0/patches/gcc-6.3.0/0010-static-pie-support.diff Acked-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* | toolchain: limit musl workaround to kernel headers 3.12+Baruch Siach2017-05-191-1/+3
|/ | | | | | | | | | | | | | The libc-compat.h first appeared in kernel version 3.12. Trying to build a musl toolchain using earlier headers leads to the following failure: /bin/sed: can't read .../output/host/usr/arm-buildroot-linux-musleabi/sysroot/usr/include/linux/libc-compat.h: No such file or directory package/pkg-generic.mk:266: recipe for target '.../output/build/toolchain/.stamp_staging_installed' failed Don't apply the sed patch to older headers. Reported-by: Florent Jacquet <florent.jacquet@free-electrons.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* Revert "toolchain-external: CodeSourcery NiosII 2015.11 affected by PR19405"Romain Naour2017-05-072-5/+0
| | | | | | | | | | | An autobuilder exception has been added to avoid testing qt gui module with the CodeSourcery NiosII toolchain. This allow to remove the BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405 symbol. This reverts commit 5dce3c05b5ea38539f6ee6efc24c13db936260dc. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: add 4.11.x choice for headersSamuel Martin2017-05-012-0/+9
| | | | | Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: CodeSourcery MIPS update upstream URLRomain Naour2017-04-301-1/+1
| | | | | | | The current URL returns error 403: Forbidden, so switch to https. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: CodeSourcery ARM update upstream URLRomain Naour2017-04-301-1/+1
| | | | | | | The current URL returns error 403: Forbidden, so switch to https. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: CodeSourcery aarch64 update upstream URLRomain Naour2017-04-301-1/+1
| | | | | | | The current URL returns error 403: Forbidden, so switch to https. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: bump CodeSourcery NIOSII to 2017.05Romain Naour2017-04-303-6/+9
| | | | | | | Tested with qemu_nios2_10m50_defconfig and Qemu 2.9.0 release. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: CodeSourcery NIOSII update upstream URLRomain Naour2017-04-301-1/+1
| | | | | | | The current URL returns error 403: Forbidden, so switch to https. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: fix handling of ld.soThomas De Schampheleire2017-04-061-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit ba6bac138331cea449592f877e558f84176a70bf made a change in copying of the dynamic loader, with the goal of reducing toolchain-specific fixups. Any ld*.so file found in the toolchain's lib directory would be copied to the staging/lib directory. For the toolchains that previously needed fixup, this new behavior is fine. The reason they needed fixup was that the normal copy action did not include any dynamic loader. However, for certain other toolchains this new behavior actually breaks things: regardless of ARCH_LIB_DIR, which may be lib64 instead of lib, the dynamic loader from lib is copied _over_ any previously correct dynamic loader. This has been witnessed with the CodeSourcery x86_64 and CodeSourcery MIPS64 toolchains. In both cases, a 32-bit dynamic loader was copied to staging/lib, while a 64-bit version was expected. Fix the problem by only performing this explicit dynamic loader copy if no dynamic loader is found in staging/lib. Fixes http://autobuild.buildroot.net/results/8bf/8bffe54032aad9cc710a22411ef3bff4a2c93e55/ Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: copy_toolchain_lib_root: copy symlinks instead of recreating themThomas De Schampheleire2017-04-051-2/+1
| | | | | | | | | | | | | | | | copy_toolchain_lib_root handles symlinks by recreating them, disregarding the original destination and assuming the destination is in the same directory as the link itself. When a library link points to the real library file in another directory, for example: usr/lib/octeon2/libcrypt.so -> ../../../lib32/octeon2/libcrypt.so.1 then the link created by copy_toolchain_lib_root is broken. It is more robust to copy the symlink to keep the destination intact. The destination path should be present, possibly through other symbolic links. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: copy_toolchain_lib_root: clarify input parameterThomas De Schampheleire2017-04-052-5/+5
| | | | | | | | | | | | | | | The input to copy_toolchain_lib_root is not one library, not a list of libraries, but a library name pattern with glob wildcards. This pattern is then passed to 'find' to get the actual list of libraries matching the pattern. Reflect this using an appropriate variable name. Note: if the root of the buildroot tree contains a file matching one of these library patterns, the copying of libraries from staging to target will not be correct. It is not impossible to fix that, e.g. using 'set -f', but maybe it's not worth it. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: copy_toolchain_lib_root: clarify logicThomas De Schampheleire2017-04-051-5/+3
| | | | | | | | | | copy_toolchain_lib_root has slightly different logic depending on the type of library object: file or link. All actions related to links are not relevant in case you are working with a file. Hence, try to increase clarity by not executing unnecessary lines in the 'file' case. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: copy_toolchain_lib_root: remove unused variable LIBDIRThomas De Schampheleire2017-04-051-1/+0
| | | | | Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: simplify previously-broken symbolic linksThomas De Schampheleire2017-04-051-0/+3
| | | | | | | | | | A previous commit rewrote broken symbolic links in staging, caused by a non-singular ARCH_LIB_DIR. In this case, the symbolic links are typically using one or more intermediate directory symlinks, which can be simplified using the newly introduced simplify_symlink helper. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain helpers: introduce simplify_symlinkThomas De Schampheleire2017-04-051-0/+27
| | | | | | | | | | | | | | | | | | | | | The external toolchain logic flattens the directory layout in the staging directory. Regardless of the number of levels present in the extracted toolchain, libraries are always copied to lib/ and usr/lib/, and directory symbolic links are provided to make the original paths available as well. Due to this, the same library may be reachable through a number of paths: one path without any symbolic link, and one or more paths using directory symlinks. Using a direct path in a symlink destination is generally preferred because it is clearer, but it is also more robust against accidental removal of an intermediate directory symlink. Introduce a helper function to simplify a symlink's destination to such a direct path. This function will be used in a subsequent patch. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: cover multilib toolchains with lib/<variant> layoutThomas De Schampheleire2017-04-052-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The toolchain from the Cavium Octeon SDK has a sysroot layout as follows: ./lib32 ./lib32/octeon2 ./lib32-fp ./lib64 ./lib64/octeon2 ./lib64-fp ./usr ./usr/lib ./usr/lib32 ./usr/lib32/octeon2 ./usr/lib32-fp ./usr/lib64 ./usr/lib64/octeon2 ./usr/lib64-fp ./usr/bin ./usr/bin32 ./usr/bin32-fp ./usr/bin64-fp ./usr/libexec ./usr/libexec32 ./usr/libexec32-fp ./usr/libexec64-fp ./usr/sbin ./usr/sbin32 ./usr/sbin32-fp ./usr/sbin64-fp ./usr/include ./usr/share ./sbin ./sbin32 ./sbin32-fp ./sbin64-fp ./etc ./var with the following selections: - lib64 : default - lib64/octeon2 : -march=octeon2 - lib64-fp : -march=octeon3 - lib32 : -mabi=n32 - lib32/octeon2 : -mabi=n32 -march=octeon2 - lib32-fp : -mabi=n32 -march=octeon3 In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the original Buildroot toolchain logic would copy both the libraries in lib32 as the subdirectory lib32/octeon2, which means that every library is installed twice (but only one of each is really needed). While ARCH_LIB_DIR is determined by the location of libc.a, which in this case is effectively: <sysroot>/usr/lib32/octeon2/libc.a the variable only retains 'lib32' and not 'lib32/octeon2' as expected. To make Buildroot cope with this style of toolchain layout, we need to adapt the calculation of ARCH_LIB_DIR to also include the second part. This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a singular path component, resulting in some additional changes. Certain older Linaro toolchains actually had the same layout. Libraries were located in lib/<tuple> rather than lib directly. Previously, this was handled by adding a toolchain-specific fixup that creates a symlink lib/<tuple> -> lib, but with this patch this would no longer be needed. Note that one difference with the Octeon case is that these Linaro toolchains are not actually multilib, i.e. there is just one location with the libraries and thus there is no problem with duplicated libraries. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain helpers: introduce function relpath_prefixThomas De Schampheleire2017-04-051-5/+20
| | | | | | | | | | | The helper function copy_toolchain_sysroot has some logic to transform a path into a number of '../' components based on the depth of that path. As this same logic will be needed in another place in a subsequent patch, extract it into a separate helper relpath_prefix. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: handle ld.so fixups centrallyThomas De Schampheleire2017-04-052-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, the Buildroot toolchain logic copies all required libraries from the external toolchain to the staging directory, including the dynamic loader ld-*.so. There are cases, however, where the dynamic loader is _not_ automatically copied to staging. This happens when the dynamic loader is not inside ARCH_LIB_DIR itself (e.g. lib64), but instead resides in 'lib' (assume, of course, that ARCH_LIB_DIR != 'lib'). Currently, this is fixed in a toolchain-specific fixup, e.g. by recreating a missing symlink or copying over a missing file. Such toolchain specific fixups are not very nice. Moreover, in a subsequent patch, the value of ARCH_LIB_DIR changes for some toolchains, causing them to have the same problem of a missing dynamic loader. This used to be the case for older Linaro toolchains with libraries in 'lib/<tuple>': Buildroot used to set ARCH_LIB_DIR=lib but the mentioned patch changes it to 'lib/<tuple>' instead. As a result, the files directly under 'lib/' will no longer be copied. There should be none, but the dynamic loader is a notable exception. [Note: support for these older Linaro toolchain has been removed in 2016.11] Instead, copy over the ld.so file(s)/link(s) from the extracted toolchain into staging, in the central copy_toolchain_sysroot function. The existing toolchain logic will then handle the copy of these files from staging to target. This means the toolchain-specific fixups can be removed. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: clarify rsync excludes in copy_toolchain_sysrootThomas De Schampheleire2017-04-051-8/+18
| | | | | | | | | | | | | | | | | | | The copy_toolchain_sysroot helper features a complex rsync loop that copies various directories from the extracted toolchain to the staging directory. The complexity mainly stems from the fact that we support multilib toolchain tarballs but only copy one of the multilib variants into staging. Increase understandability of this logic by explicitly restricting the rsync excludes to the iteration of the for loop they are relevant for. Additionally, update the function comment. Note: all attempts to reduce duplication between both rsync while keeping things nice and readable failed. One has to be extremely careful regarding line continuation, indentation, and single vs double quoting. In the end, a split up rsync seemed most clean. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/helpers.mk: remove unused argument of check_arm_abiThomas Petazzoni2017-03-262-3/+1
| | | | | | | | The check_arm_abi function takes as second argument the path to the cross-readelf, but does not use it. Therefore, this commit gets rid of this unnecessary argument. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: improve musl external checkIlya Kuzmich2017-03-262-5/+12
| | | | | | | | | | | | | The current test to verify if the toolchain uses musl or not is based on checking if /lib/libc.so or /lib/libm.so exist in the sysroot. However, some toolchains (notably Crosstool-NG ones) put these libraries in /usr/lib/. To fix this, build a minimal C program and check if the program interpreter contains /lib/ld-musl. Signed-off-by: Ilya Kuzmich <ilya.kuzmich@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: fix definition of TOOLCHAIN_EXTERNAL_READELFThomas Petazzoni2017-03-261-1/+1
| | | | | | | | | | | | | | | | TOOLCHAIN_EXTERNAL_READELF is defined to $(TOOLCHAIN_EXTERNAL_CROSS)readelf$(TOOLCHAIN_EXTERNAL_SUFFIX), where TOOLCHAIN_EXTERNAL_SUFFIX is .br_real for Buildroot toolchains. However, this is bogus, because readelf is not wrapped by the Buildroot toolchain wrapper, so "<arch>-readelf.br_real" never exists. Therefore, it should simply be defined as $(TOOLCHAIN_EXTERNAL_CROSS)readelf. Currently, TOOLCHAIN_EXTERNAL_READELF is not used anywhere, so it wasn't visible, but a follow-up commit will make use of it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
OpenPOWER on IntegriCloud