summaryrefslogtreecommitdiffstats
path: root/toolchain
Commit message (Collapse)AuthorAgeFilesLines
* toolchain-wrapper: use -ffp-contract=off on MIPS Xburst for gcc >= 4.6Waldemar Brodkorb2018-04-012-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since gcc 4.6, GCC deprecated -mfused-madd, -ffp-contract=off should be used for the Xburst workaround. Tested with the MIPS Sourcery 2011.03 toolchain (based on gcc 4.5), the toolchain wrapper uses -mno-fused-madd, as expected: $ BR2_DEBUG_WRAPPER=2 ./output/host/bin/mips-linux-gnu-gcc -o toto toto.c Toolchain wrapper executing: '/home/thomas/toolchains/mips-2011.03/bin/mips-linux-gnu-gcc' '--sysroot' '/home/thomas/projets/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot' '-mabi=32' '-msoft-float' '-mno-fused-madd' '-EL' '-march=mips32r2' '-o' 'toto' 'toto.c' And with the MIPS Sourcery 2012.09 toolchain (based on gcc 4.7), the toolchain wrapper uses -ffp-contract=off, as expected: $ BR2_DEBUG_WRAPPER=2 ./output/host/bin/mips-linux-gnu-gcc -o toto toto.c Toolchain wrapper executing: '/home/thomas/toolchains/mips-2012.09/bin/mips-linux-gnu-gcc' '--sysroot' '/home/thomas/projets/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot' '-mabi=32' '-msoft-float' '-ffp-contract=off' '-EL' '-march=mips32r2' '-o' 'toto' 'toto.c' Fixes the ci20_defconfig build: https://gitlab.com/buildroot.org/buildroot/-/jobs/60303132 Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> [Thomas: rework to continue supporting pre-gcc-4.6 toolchains, extend the commit log after doing more testing.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/*/Config.in: re-wrap help textRicardo Martincoski2018-04-014-13/+20
| | | | | | | | | ... to follow the convention <tab><2 spaces><62 chars>. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/*/Config.in: fix attributes orderRicardo Martincoski2018-04-013-8/+8
| | | | | | | ... to follow the convention: type, default, depends on, select, help. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/toolchain.mk: fix code styleRicardo Martincoski2018-04-011-10/+14
| | | | | | | | | | | | | | | | | Rearrange the header of the .mk file so it becomes similar to a header from a package. It doesn't fit in one line, so split the details to a comment below the header. GCONV_LIBS is only used inside this file, so rename it to start with TOOLCHAIN_, following the namespace convention already used by packages. Rename the hook COPY_GCONV_LIBS to TOOLCHAIN_GLIBC_COPY_GCONV_LIBS following the convention used for hooks in packages. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/wrapper: fix code styleRicardo Martincoski2018-04-011-1/+5
| | | | | | | | | | The header of the .mk file fits in one line, so rearrange it to be similar to a header from a package. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: merge toolchain-common.in to Config.inRicardo Martincoski2018-04-012-470/+470
| | | | | | | | | | | | | | | | | | toolchain-common.in is a Config.in file with an uncommon name. It is just included by toolchain/Config.in, and toolchain/Config.in is not that long, so instead of renaming the file, merge it to toolchain/Config.in. Move the raw contents from the file to the exact location it is currently included in order to not change the order in the menu. Update the references in the manual as well. Suggested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: fix detection of SSP supportCarlos Santos2018-03-252-2/+1
| | | | | | | | | | | | | | | | GCC issues a warning message if -fstack-protector is passed but SSP is not available, so in order to force the compilation to fail we must also pass -Werror. All external toolchains were verified. The only one whose configuration incorrectly selected BR2_TOOLCHAIN_HAS_SSP was CodeSourcery NIOSII. Fixes: http://autobuild.buildroot.net/results/ce8fe8ac9cf0db01ae15d476ea714ff176965cfb http://autobuild.buildroot.net/results/09ce8f05e28c0219f499ce55130e896cae0c8b45 Signed-off-by: Carlos Santos <casantos@datacom.ind.br> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* pkg-cmake: install CMake files as part of a packageThomas Petazzoni2018-03-251-3/+0
| | | | | | | | | | | | | | | | | | | | Currently, the toolchainfile.cmake and Buildroot.cmake files are installed outside of any package, just triggered by the toolchain target. As part of the per-package SDK effort, we are trying to avoid anything that installs to the global $(HOST_DIR), and this is one of the remaining files installed in $(HOST_DIR) outside of any package. We fix this by installing such files as part of the toolchain package post-install staging hooks. Yes, a post-install staging hook to install things to $(HOST_DIR) is a bit weird, but the toolchain infrastructure is made of target packages only, and they all install a lot of stuff to $(HOST_DIR) already. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: limit musl/kernel headers conflict workaroundBaruch Siach2018-02-141-6/+6
| | | | | | | | | | | | | | | | | | | | | The musl/kernel headers workaround was added in commit 196932cd91 (toolchain: workaround musl/kernel headers conflict) to fix definition collisions in networking related headers between musl headers and kernel headers. Kernel headers from version 4.15 and newer do not need this workaround anymore since kernel commit c0bace798436bc (uapi libc compat: add fallback for unsupported libcs). The C library does not have to define the __GLIBC__ macro to make the __UAPI_DEF_* macros effective. Updated the comment to accordingly. Tested with the xl2tp package. This package fails to build with older kernel headers without the workaround (struct in_pktinfo redefinition, among others). With 4.15 headers, xl2tp builds fine with this patch applied. That is, no workaround needed. Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: add 4.15.x choice for headersFabio Estevam2018-01-282-0/+9
| | | | | Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain/toolchain-external: libatomic should also be copied for musl ↵Thomas Petazzoni2018-01-171-2/+2
| | | | | | | | | | | | | | toolchains libatomic, like libgcc_s, is provided by gcc, so there is no reason to copy it over only for the glibc and uclibc cases, it should also be copied for the musl case. Without this, a program linked with libatomic on a musl system will fail to run due to the missing library. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: bump ARC prebuild toolchain to arc-2017.09Evgeniy Didin2018-01-093-10/+9
| | | | | | | | | | | | | There might be subtle differences between uClibc configuration compared to Buildroot's one. Native RPC now is disabled because uClinc-ng has removed it. Signed-off-by: Evgeniy Didin <didin@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: arc-buildroot@synopsys.com Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: m68k coldfire is also affected by gcc bug 64735Jan Heylen2018-01-071-0/+1
| | | | | | | | | | Verified experimentally by using exception_ptr with m68k_cf5208 and looking at the value of ATOMIC_INT_LOCK_FREE. ATOMIC_INT_LOCK_FREE=1, so the issue is present. Also verified that gcc 7.x fixed it also for cf5208. Signed-off-by: Jan Heylen <jan.heylen@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: post-pone evaluation of TOOLCHAIN_EXTERNAL_BINThomas Petazzoni2017-12-311-1/+1
| | | | | | | | | | | | | | | | | | The upcoming per-package SDK functionality is heavily based on the fact that HOST_DIR, STAGING_DIR and TARGET_DIR are evaluated during the configure/build/install steps of the packages. Therefore, any evaluation-during-assignment using := is going to cause problems, and need to be turned into evaluation-during-use using =. This patch fix up one such instance in the external toolchain code. This change is independent from the per-package SDK functionality, and could be applied separately. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: bump version of Linaro AArch64 toolchain to 7.2-2017.11Romain Naour2017-12-293-8/+7
| | | | | | | | | https://releases.linaro.org/components/toolchain/binaries/7.2-2017.11 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 7.2-2017.11Romain Naour2017-12-293-12/+11
| | | | | | | https://releases.linaro.org/components/toolchain/binaries/7.2-2017.11 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 7.2-2017.11Romain Naour2017-12-293-11/+9
| | | | | | | | | https://releases.linaro.org/components/toolchain/binaries/7.2-2017.11 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-external: bump version of Linaro AArch64 toolchain to 2017.11Romain Naour2017-12-153-4/+4
| | | | | | | | | https://releases.linaro.org/components/toolchain/binaries/6.4-2017.11 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.11Romain Naour2017-12-153-6/+6
| | | | | | | https://releases.linaro.org/components/toolchain/binaries/6.4-2017.11 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.11Romain Naour2017-12-153-6/+6
| | | | | | | | | https://releases.linaro.org/components/toolchain/binaries/6.4-2017.11 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>
* Merge branch 'next'Thomas Petazzoni2017-12-0114-15/+52
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This merges the next branch accumulated during the 2017.11 release cycle back into the master branch. A few conflicts had to be resolved: - In the DEVELOPERS file, because Fabrice Fontaine was added as a developer for libupnp in master, and for libupnp18 in next. Resolution is simple: add him for both. - linux/Config.in, because we updated the 4.13.x release used by default in master, while we moved to 4.14 in next. Resolution: use 4.14. - package/libupnp/libupnp.hash: a hash for the license file was added in master, while the package was bumped into next. Resolution: keep the hash for the license file, and keep the hash for the newest version of libupnp. - package/linux-headers/Config.in.host: default version of the kernel headers for 4.13 was bumped to the latest 4.13.x in master, but was changed to 4.14 in next. Resolution: use 4.14. - package/samba4/: samba was bumped to 4.6.11 in master for security reasons, but was bumped to 4.7.3 in next. Resolution: keep 4.7.3. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * musl: enable or1k architectureWaldemar Brodkorb2017-11-301-4/+4
| | | | | | | | | | | | | | | | With Linux kernel >= 4.13.x musl or1k can be used with Qemu. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * toolchain/buildroot: add comment for glibc NaN-2008 headers requirementYann E. MORIN2017-11-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4a5140ecf (toolchain/buildroot: glibc requires kernel headers >= 4.5 with NaN-2008) added a restriction on kernel headers for glibc when the architecture is using naN-2008. However, such a restriction is usually associated to a comment explaining the restriction, so the user knows what is happening. That comment was forgotten in 4a5140ecf. Add it now. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * arch/arm: armv8 is really armv8aYann E. MORIN2017-11-243-3/+3
| | | | | | | | | | | | | | | | | | | | | | For armv8, there are different profiles: A, M and R, like there is for armv7. So, rename our internal symbol to mirror what we do for armv7. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * toolchain/buildroot: glibc requires kernel headers >= 4.5 with NaN-2008Yann E. MORIN2017-11-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From sysdeps/unix/sysv/linux/mips/configure.ac in glibc: if test -z "$arch_minimum_kernel"; then if test x$libc_cv_mips_nan2008 = xyes; then arch_minimum_kernel=4.5.0 fi fi Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * arch/mips: inverse the mfpxx logicYann E. MORIN2017-11-241-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the possibility to choose the floating point mode (32, xx or 64) is conditional on having a sufficiently recent gcc version. Which means that the architecture selection depends on the gcc version. But that's opposite to what we've always done in Buildroot: the software versions are conditional to the architecture options. There is nothing we can do about the hardware: it is there, we can't change it, while we can restrict ourselves to using software that is working on said hardware. Thus, we inverse the logic, to move the condition onto the software side: whenever mfpxx is selected, we restrict the toolchain selection to at least a gcc-5. And now, the blind BR2_TOOLCHAIN_HAS_MFPXX_OPTION symbol is no longer needed, so we get rid of it. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * arch/arm: some variants need different gcc versionsYann E. MORIN2017-11-241-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take the conditions currently specified in the gcc version choice. Also, the conditions explained in the commit log for 78c2a9f7 were not all properly applied, especially the a57-a53 combo needs gcc-6, but 78c2a9f7 forgot to add the condition to gcc-4.9. gcc-4.9 was excluded for cortex-a17 and a72, but the CodeSourcery external toolchain, which uses 4.8, was not excluded for those two cores. Now it is. Remove the arch condition from gcc and the external toolchains. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * toolchain/external: hide versions too old for the current archYann E. MORIN2017-11-2411-0/+15
| | | | | | | | | | | | | | | | | | Hide the toolchains if the arch requires a gcc version more recent than the one they provide. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * toolchain/external-custom: hide versions too old for the current archYann E. MORIN2017-11-241-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an architecture expresses a requirement on the gcc version, limit the version choice in the custom external toolchain. The rationale being that there is no point in offering that version to the user if we know before-hand that the gcc version will not work for that architecture. All versions below the minimum we support is just made conditional to that minimum as well, including the "older" entry. However, this means that the "older" entry is no longer available when the architecture requires a minimum gcc version. A user who wants to use a toolchain with a gcc older than the minimum will have no choice but to realise the toolchain is not suitable (or lie and we would catch that when checking the gcc version anyway). Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * toolchain: add 4.14.x choice for headersFabio Estevam2017-11-132-0/+9
| | | | | | | | | | Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* | Fix makefile include order by using sort/wildcard.Peter Seiderer2017-11-241-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | The 'include' directive in GNU make supports wildcards, but their expansion has no defined sort order (GLOB_NOSORT is passed to glob()). Usually this doesn't matter. However, there is at least one case where it does make a difference: toolchain/*/*.mk includes both the definitions of the external toolchain packages and pkg-toolchain-external.mk, but pkg-toolchain-external.mk must be included first. For predictability, use ordered 'include $(sort $(wildcard ...))' instead of unordered direct 'include */*.mk' everywhere. Fixes [1] reported by Petr Vorel: make: *** No rule to make target 'toolchain-external-custom', needed by '.../build/toolchain-external/.stamp_configured'. Stop. [1] http://lists.busybox.net/pipermail/buildroot/2017-November/206969.html Signed-off-by: Peter Seiderer <ps.report@gmx.net> Tested-by: Petr Vorel <petr.vorel@gmail.com> [Arnout: also sort the one remaining include, of the external docs] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain/wrapper: fake __DATE_ and __TIME__ for older gccYann E. MORIN2017-10-221-2/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting with version 7, gcc automatically recognises and enforces the environment variable SOURCE_DATE_EPOCH, and fakes __DATE__ and __TIME__ accordingly, to produce reproducible builds (at least in regards to date and time). However, older gcc versions do not offer this feature. So, we use our toolchain wrapper to force-feed __DATE__ and __TIME__ as macros, which will take precedence over those that gcc may compute itself. We compute them according to the specs: https://reproducible-builds.org/specs/source-date-epoch/ https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html Since we define macros otherwise internal to gcc, we have to tell it not to warn about that. The -Wno-builtin-macro-redefined flag was introduced in gcc-4.4.0. Therefore, we make BR2_REPRODUCIBLE depend on GCC >= 4.4. gcc-7 will ignore SOURCE_DATE_EPOCH when __DATE__ and __TIME__ are user-defined. Anyway, this is of no consequence: whether __DATE__ and __TIME__ or SOURCE_DATE_EPOCH takes precedence, it would yield the exact same end result since we use the same logic to compute it. Note that we didn't copy the code for it from gcc so using the same logic doesn't imply that we're inheriting GPL-3.0. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Jérôme Pouiller <jezz@sysmic.org> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <peter@korsgaard.com> [Arnout: rewrite commit message] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: add glibc support for ARCv2Evgeniy Didin2017-10-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Finally there's working ARC port of glibc thanks to Vineet and Cuper! This port is based on pretty recent glibc's master branch and ARC changes are being reviewed now in glibc's mailing list. Thus we again have to use sources from our GitHub but as soon as there's a glibc release with our patches applied we'll switch to upstream releases and will drop our glibc GitHub repo alltogether. Note now we cut tags in glibc repo simultaneously with tags in Binutils and GCC repos and so to make sure everything works in the best way we plan to update glibc tag together with Binutils and GCC. Also note as of today ARCompact (AKA ARCv1 ISA) is not supported in glibc but we plan to fix it soonish so for now we make glibc intentionally dependent on archs38. Also note we are not creating directory "2.26" because all patches for glibc ver 2.26 applies to arc glibc port. Signed-off-by: Evgeniy Didin <didin@synopsys.com> CC: Alexey Brodkin <abrodkin@synopsys.com> CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> CC: Waldemar Brodkorb <wbx@openadk.org> CC: Romain Naour <romain.naour@gmail.com> Cc: Cupertino Miranda <cmiranda@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/bfin: internal backend not suitable for some coresYann E. MORIN2017-10-021-4/+0
| | | | | | | | | | | | Some cores are not supported by upstream gcc. 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/mips: internal backend not suitable for some coresYann E. MORIN2017-10-021-2/+0
| | | | | | | | | | | | Some cores are not supported by upstream gcc. 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/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>
OpenPOWER on IntegriCloud