buildroot/toolchain, branch 2017.11.2

toolchain/toolchain-external: libatomic should also be copied for musl toolchains

2018-01-21T20:17:28+00:00

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 Reviewed-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni (cherry picked from commit ece9385523351d20e314bddc1f277aef8de7fb40) Signed-off-by: Peter Korsgaard

toolchain: m68k coldfire is also affected by gcc bug 64735

2018-01-08T21:39:50+00:00

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 Signed-off-by: Thomas Petazzoni (cherry picked from commit 98b3b83fb54323cd1be0f38084a51c4e0c939e65) Signed-off-by: Peter Korsgaard

Fix makefile include order by using sort/wildcard.

2017-11-23T23:08:23+00:00

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 Tested-by: Petr Vorel [Arnout: also sort the one remaining include, of the external docs] Signed-off-by: Arnout Vandecappelle (Essensium/Mind)

toolchain/wrapper: fake __DATE_ and TIME for older gcc

2017-10-22T14:10:37+00:00

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" Cc: Jérôme Pouiller Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Cc: Peter Korsgaard [Arnout: rewrite commit message] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Reviewed-by: "Yann E. MORIN" Signed-off-by: Peter Korsgaard

toolchain: add glibc support for ARCv2

2017-10-10T21:13:34+00:00

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 CC: Alexey Brodkin CC: Thomas Petazzoni CC: Waldemar Brodkorb CC: Romain Naour Cc: Cupertino Miranda Cc: Vineet Gupta Cc: Anton Kolesov Signed-off-by: Thomas Petazzoni

arch/bfin: internal backend not suitable for some cores

2017-10-02T19:41:53+00:00

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" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Signed-off-by: Thomas Petazzoni

arch/mips: internal backend not suitable for some cores

2017-10-02T19:41:42+00:00

arch/csky: internal backend not suitable

2017-10-02T19:41:36+00:00

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" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Signed-off-by: Thomas Petazzoni

arch: add option to disable internal toolchain backend

2017-10-02T19:41:29+00:00

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" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Signed-off-by: Thomas Petazzoni

package/glibc: needs kernel headers >= 3.10 on powerpc64le

2017-09-27T20:56:11+00:00

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 Cc: Thomas Petazzoni Cc: "Yann E. MORIN" Reviewed-by: "Yann E. MORIN" Signed-off-by: Arnout Vandecappelle (Essensium/Mind)