summaryrefslogtreecommitdiffstats
path: root/toolchain
Commit message (Collapse)AuthorAgeFilesLines
...
* arch/csky: internal backend not suitableYann E. MORIN2017-10-021-1/+0
| | | | | | | | | | | | | Upstream gcc does not have support for C-Sky, and we do not have a vendor tree for it either (yet?). Use the newly-introduced symbol to state so, rather than have the exclusion in the toolchain choice. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: add option to disable internal toolchain backendYann E. MORIN2017-10-021-0/+1
| | | | | | | | | | | | | | | | | | | | Some architectures or specific cores do not have support in upstream gcc. Currently, they are individually listed as exclusions in the toolchain choice. This poses a maintainance burden, as the knowledge about what gcc version supports what architecture is split across many places: the toolchain choice, the gcc version choice, the external toolchains. As a first step, add a blind option that architectures or individual cores may select to indicate they lack support in our internal backend. Actual use of the option will come in followup patches. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package/glibc: needs kernel headers >= 3.10 on powerpc64leRomain Naour2017-09-271-0/+6
| | | | | | | | | | | | | | Since glibc 2.26, kernel headers >= 3.10 are needed on powerpc64le [1]. In order to prepare the glibc bump to this version, we don't allow to build a Buildroot toolchain with kernel headers older than 3.10. [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=c2ff5ec13fca1bdd1cd646a0260808386d7bd7ff Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain-external: bump version of Linaro AArch64 toolchain to 2017.08Romain Naour2017-09-273-7/+7
| | | | | | | | | | | GDB has been updated to 8.0 version in the release. https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08 Tested with qemu_aarch64_virt_defconfig. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: bump version of Linaro ARMeb toolchain to 2017.08Romain Naour2017-09-273-9/+9
| | | | | | | | | GDB has been updated to 8.0 version in the release. https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08 Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: bump version of Linaro ARM toolchain to 2017.08Romain Naour2017-09-273-9/+9
| | | | | | | | | | | GDB has been updated to 8.0 version in the release. https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08 Tested with qemu_arm_vexpress_defconfig. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: detect external glibc in merged /usrCam Hutchison2017-09-191-1/+1
| | | | | | | | | | | | | | | | | | When using an external toolchain that was built with Buildroot and a merged /usr, the dynamic linker is actually in /usr/lib. But the check_glibc macro limits the depth it is looking for the dynamic linker, and misses it when it is in /usr/lib because it is too deep. We could fix that in two ways: increase the depth in which we look for it, or follow symlinks. We choose the second solution. Signed-off-by: Cam Hutchison <camh@xdna.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain: add 4.13.x choice for headersFabio Estevam2017-09-072-0/+9
| | | | | Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain/buildroot: not available for a few mips coresYann E. MORIN2017-08-291-0/+2
| | | | | | | | | | | | | | | | | | Commit 1b974425 (MIPS: add support for M6201 cores) explained that the new core was not supported by upstream gcc, and as of gcc-8-trunk that's still the case. Ditto for 3cfbeb83 (MIPS: add support for P6600 cores). This means that we currently allow to build an internal tolchain for those cores, yet we have no suitable gcc version. Disable the internal backend in this case. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* core/pkg-toolchain-external: quiesce spurious stderrYann E. MORIN2017-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 392b0a26f5 (toolchain-external: default BR2_TOOLCHAIN_EXTERNAL_PATH to empty), calling 'make clean' or similar can yield a spurious stderr message: dirname: missing operand Try 'dirname --help' for more information. Which is definitely baffling and unsettling... It turns out that it is pretty trivial to reproduce, and this defconfig is just enough: $ cat my-defconfig BR2_TOOLCHAIN_EXTERNAL=y $ make BR2_DEFCONFIG=$(pwd)/my-defconfig defconfig $ make clean dirname: missing operand Try 'dirname --help' for more information. [--snip--] This is because the cross-compiler is not found in the PATH (and for good reasons, I don't have it in the PATH, not even at all). So, when the cross-compiler is not found in the path, we simply continue as if all was good, and postpone the check to much later, when we try to copy the toolchain libs... So, use a make construct rather than calling to the shell: $(dir ...) does not whine if passed nothing. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/arm: add big.LITTLE cpu variantsYann E. MORIN2017-07-222-0/+6
| | | | | | | | | | | | | | | | | | | | | | | The big.LITTLE configurations can be optimised for by gcc, and a few users wonder what they should choose when they have such CPUs. Add new entries for those big.LITTLE configurations. Note: the various combos were added in various gcc versions, but only really worked in later versions: Variant | Introduced in | First built in ----------+---------------+---------------- a15-a7 | 4.9 | 4.9 a17-a7 | 5 | 5 a57-a53 | 4.9 | 6 a72-a53 | 5 | 6 Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/mips: add option for toolchains supporting -mfpxxVicente Olivert Riera2017-07-211-0/+4
| | | | | | | | | | | | | -mfpxx option was added in gcc-5.1.0 so make sure that users cannot select the "xx" fp32 mode when using toolchains that have a gcc older than 5.1.0. -mfp32 and -mfp64 were added in gcc-4.1.0, so given the older gcc version we support in Buildroot (in the GCC_AT_LEAST options) is 4.3 we don't need to do anything else for them. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/mips: add option for toolchains supporting -mnanVicente Olivert Riera2017-07-212-0/+6
| | | | | | | | | | -mnan option was added in gcc-4.9.0 so make sure that users cannot select the NaN mode when using toolchains that have a gcc older than 4.9.0, and also make sure that the -mnan option is not passed at all to the toolchain-wrapper and target cflags. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/mips: add support for MIPS32 FP modeVicente Olivert Riera2017-07-162-0/+19
| | | | | | | | | | | | | | | | | | | | MIPS32 support different FP modes (32,xx,64), so give the user the opportunity to choose between them. That will cause host-gcc to be built using the --with-fp-32=[32|xx|64] configure option. Also the -mfp[32|xx|64] gcc option will be added to TARGET_CFLAGS and to the toolchain wrapper. FP mode option shouldn't be used for soft-float, so we add logic in the toolchain wrapper if -msoft-float is among the arguments in order to not append the -fp[[32|xx|64] option, otherwise the compilation may fail. Information about FP modes here: - https://sourceware.org/binutils/docs/as/MIPS-Options.html - https://dmz-portal.imgtec.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#5._Generating_modeless_code Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* 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>
OpenPOWER on IntegriCloud