Commit Graph

2472 Commits

Author SHA1 Message Date
Guo Ren
f7f568f5e0 arch: add support for the csky architecture
This commit provides basic support for the C-SKY architecture.

Signed-off-by: Guo Ren <ren_guo@c-sky.com>
[Thomas: minor tweaks.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-04 14:35:55 +01:00
Thomas De Schampheleire
bb924a0489 toolchain-external: fix broken handling of 'usr/lib/locale'
Function copy_toolchain_sysroot, which is in charge of copying the relevant
bits from the external toolchain to the staging directory, performs an rsync
loop of various directories and excludes the pattern 'usr/lib/locale' with
the intention of skipping the directory <toolchain>/usr/lib/locale.

However, while this worked in the original commit, commit
5628776c4a broke it inadvertently. The
relevant part of the diff:

-    rsync -au --chmod=Du+w --exclude 'usr/lib/locale' \
-          $${ARCH_SYSROOT_DIR}/$$i $(STAGING_DIR)/ ; \
+    rsync -au --chmod=Du+w --exclude 'usr/lib/locale' \
+          --exclude lib --exclude lib32 --exclude lib64 \
+          $${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \

Notice how the source directory now contains a trailing slash, which impacts
the way the exclude rules are interpreted. Previously, when 'i' was 'usr',
the exclude of 'usr/lib/locale' would find a match. With the trailing slash,
there will never be a match, unless for a directory 'usr/usr/lib/locale'.
The right rule would have been '--exclude lib/locale'.

However, just that fix does not solve the problem in all cases, in
particular in the (common) case where ARCH_LIB_DIR is 'lib'. This is due
another change in that commit, changing the iterated values of the above
rsync:

- for i in etc $${ARCH_LIB_DIR} sbin usr ; do \
+ for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \

Due to the fact that we rsync both 'usr' as 'usr/lib' (assuming ARCH_LIB_DIR
is 'lib') we need to add the correct exclude in both cases. But the exclude
is different for both. When i == 'usr', the correct exclude rule would be
'--exclude lib/locale' while when i == 'usr/lib' the correct rule would be
'--exclude locale'.

Since we would like to avoid separate cases for this, use the following
exclude: '--exclude locale/'. The trailing slash will make sure only
directories called 'locale' will match. The targeted directories are then
usr/lib/locale and usr/share/locale. The latter directory was not matched
originally, but it should not hurt changing that.

Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-01 23:23:35 +01:00
Thomas De Schampheleire
a07e47a47f toolchain-external: reduce nesting in copy_toolchain_sysroot
As discussed with Thomas Petazzoni, we can reduce the nesting level by early
returning on an invalid iteration.

I did not move the 'else' case (the common case) outside the if-else because
it would make the code less symmetrical and IMO makes it _less_ clear.

Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-01 23:21:54 +01:00
Yann E. MORIN
c69b14fe2f core/pkg-cmake: provide our own platform description
The handling of RPATH in cmake-3.7 has changed drastically, causing a
slew of build failures dues to libraries from the host being pulled in:

  - domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54c7abf973691b39a0ca1bb4e07d749593a/
  - freerdp  : http://autobuild.buildroot.org/results/5d4/5d429d0e288754a541ee5d8be515454c5fccd28b/
  - libcec   : http://autobuild.buildroot.org/results/3f3/3f3593bab7734dd274faf5b5690895e9424cbb89/
  - and so on...

The bug was reported upstream [0], which dismissed it altogether [1] as
being expected behaviour, quoting:

    I don't think there is anything wrong with that change on its own.
    It merely exposed some existing behavior in a new case.

Instead, upstream suggested in that same message that a platform
definition be used instead, quoting:

    If a toolchain file specifies CMAKE_SYSTEM_NAME such that a custom
    `Platform/MySystem.cmake` file is loaded then the latter can set
    them as needed for the target platform.

So here we are doing so:

  - we add a new platfom definitions that inherits from the Linux one,
    then overrides the problematic settings;

  - we change our toolchain file to use that platform instead;

  - we tell cmake where to find additional modules, so that it can find
    our custom platform file.

This has been tested to work in the following conditions:

 - pre-installed host cmake, versions 3.5.1 (Ubuntu 16.04) and 3.7.2
   (manually built)

  - internal cmake, versions 3.6.3 (the current version as of this
    patch) and 3.7.2 (with the followup patches).

Thanks to Jörg, Ben and Baruch for the help investigating the issue.
Special thanks to Jörg for handling the discussion with upstream and
pointing to the relevant messages! :-)

[0] http://public.kitware.com/pipermail/cmake/2017-February/064970.html
[1] http://public.kitware.com/pipermail/cmake/2017-February/065063.html

To be noted: Thomas suggested we set these directly in the toolchain
file. Unfortunately, wherever we put those settings in the toolchain
file, this does not work.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-01 21:56:24 +01:00
Peter Korsgaard
fd89246426 Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-03-01 17:37:33 +01:00
Jesper Baekdahl
e9abb4a8b4 toolchain-external: install libanl.so for glibc
libanl.so is needed for asynchronous network address and service
translation, declared in netdb.h

Signed-off-by: Jesper Bækdahl <jbb@gamblify.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-24 12:02:29 +01:00
Yann E. MORIN
1c8c0d91a4 Revert "reproducible: fix DATE/TIME macros in toolchain-wrapper"
This reverts commit 76838f6341.

The commit referenced above explicitly states that the function was
copied as-is from the gcc source code at the time. And indeed that is
exactly how the function appeared in gcc in commit
e3e8c48c4a494d9da741c1c8ea6c4c0b7c4ff934.

However, our toolchain wrapper is "GPLv2 only", while the file this function
was copied from is "GPLv3 or later".  As such we can't include that function
and still comply to both licenses.

Furthermore, the code is far from optimum.

Since this feature is not release-critical, revert it until we re-implement
it.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jérôme Pouiller <jezz@sysmic.org>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-02-20 23:26:05 +01:00
Romain Naour
641fe0e392 toolchain-external: bump Linaro AArch64 toolchain to 2017.02
Tested with qemu-2.7.1-2.fc25 and the qemu_aarch64_virt_defconfig

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-20 21:58:53 +01:00
Romain Naour
52f059f38d toolchain-external: bump Linaro ARMeb toolchain to 2017.02
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-20 21:58:46 +01:00
Romain Naour
075d26900b toolchain-external: bump Linaro ARM toolchain to 2017.02
Tested with qemu-2.7.1-2.fc25 and the qemu_arm_vexpress_defconfig

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-20 21:58:40 +01:00
Fabio Estevam
369b66fc36 toolchain: add 4.10.x choice for headers
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-20 21:55:55 +01:00
Thomas Petazzoni
ded5a12482 toolchain/toolchain-common.in: fix definition of BR2_TOOLCHAIN_HAS_GCC_BUG_64735
The rework done on commit
accba02a47 ("toolchain: add option for
toolchains affected by GCC PR libstdc++/64735") by me was wrong. The
BR2_TOOLCHAIN_HAS_GCC_BUG_64735 option should be enabled when the bug is
present in the toolchain, not the opposite.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-09 21:31:28 +01:00
Jörg Krause
accba02a47 toolchain: add option for toolchains affected by GCC PR libstdc++/64735
exception_ptr, nested_exception, and future from libstdc++ are not
available for architectures not supporting always lock-free atomic ints
before GCC 7.

Bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735

Fix available starting from GCC 7 (not yet released):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=244051

Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
[Thomas:
 - directly define the value where BR2_TOOLCHAIN_HAS_GCC_BUG_64735
   rather than having additional patches touching affected architectures
   Config.in files
 - add a better comment above the Config.in option.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-09 21:26:22 +01:00
Jérôme Pouiller
76838f6341 reproducible: fix DATE/TIME macros in toolchain-wrapper
The use of the __DATE__ and __TIME__ macros are one of the most common
sources of non-reproducible binaries. In order to fix that, gcc 7 supports
the SOURCE_DATE_EPOCH variable:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8ea6c4c0b7c4ff934

This patch take advantage of toolchain-wrapper to provide support of
SOURCE_DATE_EPOCH to older gcc versions.

Function get_source_date_epoch() come directly from gcc git.

This work was sponsored by `BA Robotic Systems'.

[Peter: use sizeof for character array sizes, make function static,
	extend commit message, add upstream gcc commit]
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-02-07 21:45:01 +01:00
Alexey Brodkin
971a13472d toolchain-external: Update Synopsys prebuilt toolchain for ARC cores
Sync external prebuilt toolchain with the one we now build in Buildroot,
i.e. arc-2016.09. Since that prebuilt toolchain finally has IPv6 enabled
it works pretty fine for building packages in Buildroot.

Still note:
 1) There might be subtle differences between uClibc configuration
    compared to Buildroot's one.
 2) A couple of patches we apply on top of Builroot-built toolchain
    are obviously missing in the prebuilt version - they will be
    available in the next release.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Vlad Zakharov <vzakhar@synopsys.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-04 23:57:43 +01:00
Waldemar Brodkorb
00995e0e49 uclibc: allow to build aarch64 internal toolchain
uClibc-ng from 1.0.22 and up supports aarch64 architecture.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-02-03 20:58:56 +01:00
Waldemar Brodkorb
2b3d493095 uclibc: enable mips{32,64}r6 support
The config for ISA choice is removed for a long time as
the buildsystem does not pass -march=mips* to the compiler anymore.
For mips{32,64}r6 support NAN selection is required.

Tested with qemu mips32/mips64 defconfigs.

A small patch is required. Bug found while testing qemu defconfigs.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-02-03 20:56:18 +01:00
Thomas De Schampheleire
497f69889d toolchain-external: remove stale references to (ARCH_)LIBC_A_LOCATION
The variables LIBC_A_LOCATION and ARCH_LIBC_A_LOCATION were killed in commit
646bd86908 but the corresponding descriptions
were never removed.

Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-01 22:04:49 +01:00
Romain Naour
ae84d56331 toolchain-external: bump CodeSourcery AMD64 to 2016.11-19
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-01-27 22:22:56 +13:00
Waldemar Brodkorb
a818e29e76 arch: add OpenRISC architecture support
Add support for OpenRISC. See here for more details about
OpenRISC http://openrisc.io.

All buildroot included upstream binutils versions are supported.
Gcc support is not upstream, to be able to enable musl C library
support later, we use the branch with musl support.
At the moment it is possible to build a musl based toolchain,
but bootup in Qemu fails.

Gdb is only working to debug bare-metal code, there is no support
for gdbserver/gdb on Linux, yet.

[Peter: drop ?= for GCC_SOURCE]
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-01-25 22:53:53 +01:00
Vicente Olivert Riera
238cdff39d toolchain: bump Codescape MTI MIPS version to 2016.05-06
Also...

  - Fix a typo in Config.in
  - Take into account the host's architecture to download the x86 or
    x86_64 version. This makes the IA32 libs dependency in unnecessary.

[Peter: fix kernel headers comment as pointed out by Romain]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-01-16 13:10:24 +01:00
Vicente Olivert Riera
56016c27b2 toolchain: bump Codescape IMG MIPS version to 2016.05-06
Also...

- Fix a typo in Config.in
- Take into account the host's architecture to download the x86 or
  x86_64 version. This makes the IA32 libs dependency in unnecessary.

[Peter: fix kernel headers comment as pointed out by Romain]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-01-16 11:56:11 +01:00
Romain Naour
b3c6181de8 toolchain-external: bump CodeSourcery NIOSII to 2016.11
Keep BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405 since it's not fixed in
Binutils 2.26.

Runtime tested with an experimental version of Qemu 2.7 for Nios2.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-27 23:36:42 +01:00
Baruch Siach
4470dd9b1b toolchain: extend musl workaround for recent kernels
Kernels v4.7 and newer[1] require the __USE_MISC macro for libc-compat.h
suppressions to be effective. musl does not define this macros, so add an
unconditional definition of __USE_MISC to libc-compat.h.

In addition, since musl define IFF_LOWER_UP and friends as macros (instead of
enums), define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO to
suppress the kernel corresponding definitions to avoid conflict.

Fixes (xl2tp):
http://autobuild.buildroot.net/results/0b9/0b9384c4beaac85f3a17c3245c8a7418c2e2e296/
http://autobuild.buildroot.net/results/657/657bc5687cf01aee38d32d45ba57fb62b2bd56d0/
http://autobuild.buildroot.net/results/bcd/bcd81618de2f745a19c923c66d787b5182bb54aa/

[1] Since commit f0a3fdca79 (uapi glibc compat: fix compilation when
    !__USE_MISC in glibc)

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-17 15:26:11 +01:00
Romain Naour
63abbcce37 toolchain-external: remove musl-cross prebuilt toolchain
The upstream link to download musl-cross prebuilt toolchain is dead [1] and
there no new download location. Also the last prebuilt toolchain use musl
1.1.12 version which is not uptodate (currently 1.1.15).

Remove this support and recommend to use Buildroot toolchain instead.

[1] https://googledrive.com/host/0BwnS5DMB0YQ6bDhPZkpOYVFhbk0

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-17 14:21:00 +01:00
Fabio Estevam
94025035e4 toolchain: add 4.9.x choice for headers
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-12 00:02:03 +01:00
Yann E. MORIN
3eccf76201 toolchain/wrapper: use the {str, len} tuples for the unsafe paths
In 61cb120 (toolchain/wrapper: extend paranoid check to -isystem), we
introduced a {str,len} tuple to check the various arguments pased to
gcc, to avoid hard-coding an ever-growing, long list of those args
directly in the condition check.

Now, we're left with a long list of unsafe paths, somehow hidden within
the code, which can use the same mechanism we use for arguments.

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>
2016-12-11 15:45:06 +01:00
Yann E. MORIN
31c093e6d0 toolchain/wrapper: make the {str, len} tuple more generic, add comments
In 61cb120 (toolchain/wrapper: extend paranoid check to -isystem), we
introduced a {str,len} tuple to check the various arguments passed to
gcc, to avoid hard-coding an ever-growing, long list of those args
directly in the condition check.

It was made specific to the arguments (the structure member is named
'arg'), but can also be used to store the unsafe paths as well.

Also, that piece is almost un-documented.

Rename the structure member so that it is more generic, and add a bit of
comments to explain the whole of it.

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>
2016-12-11 15:44:44 +01:00
Peter Korsgaard
36e2a2c000 toolchain-external: disallow sourcery codebench ARM toolchain for ARMv8 cores
This toolchain uses GCC 4.8.x, which doesn't support the ARMv8 cores.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-06 21:38:24 +01:00
Thomas Petazzoni
141358d838 toolchain-external-linaro-{arm,armeb}: allow on ARMv8
The Linaro toolchains are currently only available on ARMv7-A, but can
in fact also be used to generate 32 bits code for ARMv8 platforms. This
commit therefore adjusts their architecture dependency.

Example, a 32 bits ARM build produces a 32 bits busybox binary:

$ file output/target/bin/busybox
output/target/bin/busybox: setuid ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=16a7a70eb9cac08759e52a260478b9c287f59238, stripped

Which was built for Cortex-A72:

$ ./output/host/usr/bin/arm-linux-gnueabihf-readelf -A output/target/bin/busybox
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "Cortex-A72"
  Tag_CPU_arch: v8
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: FP for ARMv8
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6
  Tag_MPextension_use: Allowed
  Tag_Virtualization_use: TrustZone and Virtualization Extensions

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:16:56 +01:00
Peter Korsgaard
44d2cc99a4 Merge branch 'next'
My local 'next' branch was not uptodate, so the previous merge was missing
the most recent changes.

Thanks to François Perrad for noticing.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-02 08:53:56 +01:00
Peter Korsgaard
8852f08eed Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-01 22:29:56 +01:00
Romain Naour
c72cca94b8 toolchain-external: bump Linaro AArch64 toolchain to 2016.11
Tested with Qemu v2.7.0 and the qemu_aarch64_virt_defconfig

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-30 21:57:24 +01:00
Romain Naour
5f4d9adc6d toolchain-external: bump Linaro ARMeb toolchain to 2016.11
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-30 21:57:14 +01:00
Romain Naour
cacfea6c26 toolchain-external: bump Linaro ARM toolchain to 2016.11
Tested with qemu-2.4.1-11.fc23 and the qemu_arm_vexpress_defconfig

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-30 21:57:03 +01:00
Arnout Vandecappelle
311bc137da toolchain: kill ADI Blackfin toolchain
This toolchain has many problems which are fixed in contemporary gcc
and uClibc-ng. In addition, several hacks are needed to be able to
work with this toolchain. All these hacks are removed as well.  Also
the package exceptions for this toolchain are removed.

The BR2_BFIN_INSTALL_FDPIC_SHARED and BR2_BFIN_INSTALL_FLAT_SHARED
options don't get a legacy entry. For the ADI toolchain, there already
is a legacy entry, so it doesn't make sense to add it twice. For other
external toolchains, these options didn't actually work, because they
rely on the specific layout of the ADI toolchain.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-25 23:00:01 +01:00
Arnout Vandecappelle
006ba68a30 toolchain-external: support gcc < 4.3
We currently support gcc as old as 4.3. However, Buildroot works
perfectly well with even older gcc versions (tested with 4.1). So we
can add an option BR2_TOOLCHAIN_EXTERNAL_GCC_OLD to support that. The
help text of this option is written with plenty of discouragement.

We use _OLD and not something like _PRE_4_3, because at some point we
will likely remove the 4.3 option and what would then require a name
change.

We don't set any _AT_LEAST option in this case because it's no use -
there is no lower bound on the version in this case. We therefore leave
BR2_TOOLCHAIN_GCC_AT_LEAST empty (the implicit default). When it is
empty, we don't do a version check at all in check_gcc_version
(previously we errored out when it was empty).

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-25 22:59:10 +01:00
Arnout Vandecappelle
b5c00f0908 toolchain-external: remove Arago toolchains
The Arago toolchains are no longer maintained and haven't been updated
for a long time.

With this removal, all the legacy toolchain-external support can be
removed as well.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:32:14 +01:00
Thomas Petazzoni
a7ec358152 toolchain-external-arc: new package
This commit adds a new package for the Synopsys external toolchain for
the ARC architecture.

The legacy implementation is removed.

Note that this toolchain is marked as BROKEN, but 2016.09 seems about
to be released so maybe it will be unbroken soon.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:31:34 +01:00
Thomas Petazzoni
ec54092c91 toolchain-external-custom: new package
This commit adds a new package to support custom external toolchains.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:23:32 +01:00
Thomas Petazzoni
06ba7f9e1c toolchain-external-musl-cross: new package
This commit adds a new package for the pre-built Musl external
toolchains.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:22:59 +01:00
Thomas Petazzoni
25429ba260 toolchain-external-codesourcery-x86: new package
This commit adds a new package for the Sourcery CodeBench external
toolchain for the i386/x86_64 architecture.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:19:27 +01:00
Romain Naour
a66b8191f4 toolchain-external-codesourcery-amd64: new package
This commit adds a new package for the Sourcery CodeBench external
toolchain for the AMD-64 architecture.

The legacy implementation is removed.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:19:19 +01:00
Thomas Petazzoni
a3b686591c toolchain-external-codesourcery-sh: new package
This commit adds a new package for the Sourcery CodeBench external
toolchain for the SuperH 4a architecture.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:19:12 +01:00
Thomas Petazzoni
f61661bc51 toolchain-external-codesourcery-niosII: new package
This commit adds a new package for the Sourcery CodeBench external
toolchain for the nios-II architecture.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:18:56 +01:00
Thomas Petazzoni
c4a62fa627 toolchain-external-codescape-mti-mips: new package
This commit adds a new package for the Codescape MTI external toolchain
for the MIPS architecture.

The legacy implementation is removed.

The Codescape hacks for IMG and MTI are duplicated.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:18:41 +01:00
Thomas Petazzoni
95c75fc834 toolchain-external-codescape-img-mips: new package
This commit adds a new package for the Codescape IMG external toolchain
for the MIPS architecture.

The legacy implementation is removed.

The Codescape hacks for IMG and MTI are duplicated.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:18:28 +01:00
Thomas Petazzoni
1e1bef57fb toolchain-external-codesourcery-mips: new package
This commit adds a new package for the Sourcery CodeBench external
toolchain for the MIPS architecture.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:18:22 +01:00
Thomas Petazzoni
cfacefecc3 toolchain-external-blackfin-uclinux: new package
This commit adds a new package for the Analog Devices external toolchain
for the Blackfin architecture.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:18:14 +01:00
Thomas Petazzoni
c428f45638 toolchain-external-linaro-armeb: new package
This commit adds a new package for the Linaro external toolchain for the
ARM Big-endian architecture.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:18:00 +01:00
Arnout Vandecappelle
71a66e8bec toolchain-external-codesourcery-arm: Cortex-A12 and Cortex-A17 not supported
It's gcc 4.8.3 which doesn't support those cores yet.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:17:00 +01:00
Thomas Petazzoni
5b3c5b336b toolchain-external-codesourcery-arm: new package
This commit adds a new package for the Sourcery CodeBench external
toolchain for the ARM architecture.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:11:06 +01:00
Thomas Petazzoni
21cb9d4c8a toolchain-external-linaro-arm: new package
This commit adds a new package for the Linaro external toolchain for the
ARM architecture.

The legacy implementation is removed.

The comment about availability is duplicated for arm and armeb.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:10:56 +01:00
Thomas Petazzoni
f0f2498c7f toolchain-external-codesourcery-aarch64: new package
This commit adds a new package for the Sourcery CodeBench external
toolchain for the AArch64 architecture.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:10:41 +01:00
Thomas Petazzoni
f1f2ae5f26 toolchain-external-linaro-aarch64: new package
This commit adds a new package for the Linaro external toolchain for
the AArch64 architecture.

The legacy implementation is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:10:33 +01:00
Arnout Vandecappelle
1c99d70e52 toolchain-external: introduce toolchain-external-package
The toolchain-external-package infrastructure is just a copy of the
toolchain-external commands, replacing TOOLCHAIN_EXTERNAL by $(2)
and adding double-dollars everywhere.

toolchain-external itself is converted to a virtual package, but it
is faked a little to make sue the toolchains that haven't been
converted to toolchain-external-package yet keep on working.

The TOOLCHAIN_EXTERNAL_MOVE commands don't have to be redefined
for every toolchain-external-package instance, so that is moved
out into the common part of pkg-toolchain-external.mk.

The musl-compat-headers dependency stays in the toolchain-external
package itself.

The musl ld link is duplicated in the legacy toolchain-external and
the toolchain-external-package, because they have separate hooks.

The handling of TOOLCHAIN_EXTERNAL_BIN deserves some special attention,
because its value will be different for different
toolchain-external-package instances. However, the value only depends
on variables that are set by Kconfig (BR2_TOOLCHAIN_EXTERNAL_PREFIX
and BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD) so it can easily be used in
the generic part. So we don't have to do anything specific for this
variable after all.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Romain Naour <romain.naour@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:09:52 +01:00
Arnout Vandecappelle
da20a8b43d toolchain-external: move parts to pkg-toolchain-external.mk
pkg-toolchain-external.mk will be used later to define the
toolchain-external-package infra. Most of the variable and macro
definitions are shared with the legacy generic-package based
toolchain-external. Move these to pkg-toolchain-external.mk.

pkg-toolchain-external.mk is included implicitly by the include
toolchain/*/*.mk in the top-level Makefile. The order of inclusion is
not defined, but that doesn't matter because none of the variables
defined in pkg-toolchain-external.mk are used in conditions or in
rules in toolchain-external.mk, only in recursively-expanded
variables.

No functional changes at all. The output of 'make -qp' hasn't changed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Arnout: split off into separate patch]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:05:00 +01:00
Arnout Vandecappelle
6d98b57527 toolchain-external: reorder the contents of toolchain-external.mk
When the toolchain-external logic will be split into separate packages,
the order in which things are defined in toolchain-external.mk no
makes less sense. So reorder things in a more logical fashion.

Also add a few more comments to the different sections.

No functional changes at all. The output of 'make -qp' hasn't changed,
except for the order of arguments in
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Arnout: split off into separate patch, slightly change some comments,
 reordered some parts]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23 22:04:18 +01:00
Baruch Siach
196932cd91 toolchain: workaround musl/kernel headers conflict
Rick Felker suggested[1] this hack as a workaround to musl libc conflict with
kernel headers:

  The problem is linux/libc-compat.h, which should fix this, only works
  on glibc, by design. See:

  #ifndef _LIBC_COMPAT_H
  #define _LIBC_COMPAT_H

  /* We have included glibc headers... */
  #if defined(__GLIBC__)

  /* Coordinate with glibc netinet/in.h header. */
  #if defined(_NETINET_IN_H)

  If you patch it like this:

  -#if defined(__GLIBC__)
  +#if 1

  then it should mostly work but it's still all a big hack. I think
  that's what distros are doing. The problem is that the same header is
  trying to do two different things:

  1. Provide extra linux-kernel-API stuff that's not in the
     libc/userspace headers.

  2. Provide definitions of the standard types and constants for uClibc
     and klibc, which don't have complete libc headers and rely on the
     kernel headers for definitions.

  These two uses really should be separated out into separate headers so
  that the latter only get included explicitly by uClibc and klibc and
  otherwise remain completely unused. But that would require coordinated
  changes/upgrades which are unlikely to happen. :(

Upstream musl still evaluates[2][3] a permanent solution.

With this in place we can revert (at least) commits a167081c5d (bridge-utils:
fix build with musl) and e74d4fc493 (norm: add patch to fix musl build).

[1] http://www.openwall.com/lists/musl/2015/10/08/2
[2] http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
[3] http://www.openwall.com/lists/musl/2016/11/09/2

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-16 23:17:48 +01:00
Vicente Olivert Riera
b2bae3b523 MIPS: rename M5101 core to M5150
m5101 is the -march option for GCC, but the real core name is M5150.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09 22:41:51 +01:00
Vicente Olivert Riera
84bd58d5bb MIPS: remove M5100 core
This is a microcontroller class (MCU) core which is not suitable for
running Linux.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09 22:41:07 +01:00
Vicente Olivert Riera
240564a693 arch/Config.in.mips: add support for XBurst cores
The Ingenic XBurst is a MIPS32R2 microprocessor.

It has a bug in the FPU that can generate incorrect results in certain
cases. The problem shows up when you have several fused madd
instructions in sequence with dependant operands.

Using the -mno-fused-madd option prevents gcc from emitting these
instructions. This patch adds changes to the toolchain wrapper to use
that option.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09 21:36:34 +01:00
Vicente Olivert Riera
d2da85c396 toolchain-external.mk: fix ARCH_SUBDIR calculation
ARCH_SUBDIR is computed based on the value of ARCH_SYSROOT_DIR and
SYSROOT_DIR. For nested toolchains ARCH_SYSROOT_DIR is a subdir of
SYSROOT_DIR, so a sed command like this one...

  sed -r -e "s:^${SYSROOT_DIR}(.*)/$:\1:"

...basically removes the leading SYSROOT_DIR part from ARCH_SYSROOT_DIR.

But, for side-by-side sysroot toolchains ARCH_SYSROOT_DIR and
SYSROOT_DIR are at the same level, so the above sed command doesn't
make any effect.

This patch therefore improves the calculation of ARCH_SUBDIR to
clearly handle the three possible cases:

 - There is a single sysroot, or the selected architecture sysroot is
   the main one (i.e SYSROOT_DIR == ARCH_SYSROOT_DIR). In this case,
   ARCH_SUBDIR is empty.

 - There are side-by-side sysroots, such as
   SYSROOT_DIR=.../sysroot/mips-r2-hard/ and
   ARCH_SYSROOT_DIR=.../sysroot/mipsel-r2-hard/.

 - The arch-sysroot is nested, such as SYSROOT_DIR=.../sysroot and
   ARCH_SYSROOT_DIR=.../sysroot/armv4t/

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas: improve the logic to handle the SYSROOT_DIR==ARCH_SYSROOT_DIR
case.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-28 14:28:49 +02:00
Thomas Petazzoni
447e9051f3 toolchain-external: install libmvec.so from glibc toolchains
On some architectures (namely x86-64), glibc may provide a libmvec
library since glibc 2.22, which programs built with gcc OpenMP support
might get linked to.

In order for these programs to work on the target, we need to copy
this library to the target filesystem.

This commit takes care of this for the external toolchain
situation. Note that libraries listed in TOOLCHAIN_EXTERNAL_LIBS are
silently ignored if they don't exist. Therefore, we don't need to have
any condition on the architecture or glibc version.

For more details on libmvec, see
https://sourceware.org/glibc/wiki/libmvec.

Fixes bug #9111.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-27 10:41:44 +02:00
Petri Gynther
8218ab8019 toolchain: configs: improve toolchain config readability
Add (or move) comment lines in toolchain-related Config.in files
to improve readability of the toolchain config section.

Source linux-headers/Config.in.host after toolchain-buildroot items.

For toolchain-buildroot case, the config file now looks like this:
*
* Toolchain
*

*
* Toolchain Buildroot Options
*

*
* Kernel Header Options
*

*
* uClibc Options
*

*
* Binutils Options
*

*
* GCC Options
*

*
* Host GDB Options
*

*
* Toolchain Generic Options
*

Signed-off-by: Petri Gynther <pgynther@google.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-25 23:31:47 +02:00
Jérôme Pouiller
8087b02bdf toolchain/wrapper: fix 'reinstall'
toolchain-wrapper was not reinstalled. So rules toolchain-external-reinstall,
gcc-initial-reinstall, gcc-final-reinstall didn't work as expected.

In add, normalize variable name: s/TOOLCHAIN_BUILD_WRAPPER/TOOLCHAIN_WRAPPER_BUILD/

Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-24 23:02:33 +02:00
Romain Naour
70f76e05b9 toolchain/external: remove unused Linaro symlink hook
This hook was needed by 1014.09 Linaro toolchains.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-16 13:08:21 +02:00
Romain Naour
fe3f9ecfec toolchain/external: bump Linaro AArch64 to 2016.05 for i686 hosts
Tested with Qemu 2.6.1 and qemu_aarch64_virt_defconfig and with
HOSTARCH set to x86 in the Buildroot main Makefile.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-16 13:08:14 +02:00
Romain Naour
9c9ddc4a2c toolchain/external: bump Linaro ARMeb to 2016.05 for i686 hosts
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-16 13:08:05 +02:00
Romain Naour
3411db085d toolchain/external: bump Linaro ARM to 2016.05 for i686 hosts
This Linaro release provide a new toolchain archive for i686 hosts, so update our
old 2014.09.

Tested with Qemu qemu-2.4.1-11.fc23 and with HOSTARCH set to x86 in the Buildroot
main Makefile.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-16 13:07:59 +02:00
Vicente Olivert Riera
b890bd1f04 toolchain-buildroot: enable Musl for MIPS R6
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 16:38:05 +02:00
Vicente Olivert Riera
55a37eaa91 MIPS: add support for M5101 cores
-march=m5101 support starts from GCC-6, so disable previous versions
when selecting this core.

Note that M5101 implies a MIPS R5 CPU, and some GCC versions are already
disabled for R5, so we don't need to disable those ones for M5101 as
well.

Also disable external toolchains that don't support this core.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
067a46474a MIPS: add support for M5100 cores
-march=m5100 support starts from GCC-6, so disable previous versions
when selecting this core.

Note that M5100 implies a MIPS R5 CPU, and some GCC versions are already
disabled for R5, so we don't need to disable those ones for M5100 as
well.

Also disable external toolchains that don't support this core.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
ef3e7323ef MIPS: add support for interAptiv cores
-march=interaptiv support starts from GCC-6, so disable previous
versions when selecting this core.

Also disable external toolchains that don't support this core.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
2373ce2763 MIPS: enable Codescape MTI toolchain for R5
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
45c92c60b1 MIPS: replace every BR2_mips_* with the new MIPS CPU options
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Waldemar Brodkorb
9f4483f7ce toolchain: update comment about uClibc/uClibc-ng
External toolchains can use both, so mention it here.

Reported-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 11:13:45 +02:00
Romain Naour
62658cf4c9 toolchain-external: bump version of Linaro AArch64 toolchain
Tested with Qemu 2.6.1 and qemu_aarch64_virt_defconfig.
As reported by Gustavo Zacarias, this defconfig is known to fail with qemu
versions lower than 2.6.0.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-25 22:00:56 +02:00
Romain Naour
93e82b6630 toolchain-external: bump version of Linaro ARMeb toolchain
The gdb version is 7.11.1 not 7.10 as stated in the link below [1].
See the manifest to check the version really used [2].

[1] https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05
[2] https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/armeb-linux-gnueabihf/gcc-linaro-5.3.1-2016.05-linux-manifest.txt

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-25 22:00:49 +02:00
Romain Naour
227553b614 toolchain-external: bump version of Linaro ARM toolchain
The gdb version is 7.11.1 not 7.10 as stated in the link below [1].
See the manifest to check the version really used [2].

Tested with Qemu 2.4.1 and qemu_arm_vexpress_defconfig.

[1] https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05
[2] https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/arm-linux-gnueabihf/gcc-linaro-5.3.1-2016.05-linux-manifest.txt

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-25 22:00:38 +02:00
Yann E. MORIN
61cb120ee5 toolchain/wrapper: extend paranoid check to -isystem
Some packages, like libbsd, use -isystem flags to provide so-called
overrides to the system include files. In this particular case, this
is used in a .pc file, then used by antoher package; pkgconf does not
mangle this path; and eventually that other package ends up using
/usr/include/bsd to search for headers.

Our current toolchain wrapper is limited to looking for -I and -L, so
the paranoid check does not kick in.

Furthermore, as noticed by Arnout, there might be a bunch of other
so-unsafe options: -isysroot, -imultilib, -iquote, -idirafter, -iprefix,
-iwithprefix, -iwithprefixbefore; even -B and --sysroot are unsafe.

Extend the paranoid check to be able to check any arbitrary number of
potentially unsafe options:

  - add a list of options to check for, each with their length,
  - iterate over this list until we find a matching unsafe option.

Compared to previously, the list of options include -I and -L (which we
already had) extended with -idirafter, -iquote and -isystem, but leaving
all the others noticed by Arnout away, until we have a reason for
handling them.

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>
2016-09-18 16:09:23 +02:00
Yann E. MORIN
105a8c156c toolchain/wrapper: display options leading to a paranoid failure
Current, we only display the path that causes the paranoid failure. This
is sufficient, as we can fail only for -I and -L options, and it is thus
easy to infer from the path, which option is the culprit.

However, we're soon to add a new test for the -isystem option, and then
when a failure occurs, we would not know whether it was because of -I or
-isystem. Being able to differentiate both can be hugely useful to
track down the root cause for the unsafe path.

Add two new arguments to the check_unsafe_path() function: one with the
current-or-previous argument, one to specify whether it has the path in
it or not. Print that in the error message, instead of just the path.

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>
2016-09-18 16:07:35 +02:00
Thomas Petazzoni
b171466c44 toolchain-external: fix potential entire root filesystem removal
This reverts commit a0aa7e0e17 and reworks
the code to fix a major and potentially catastrophic bug when the
following conditions are met:

 - The user has selected a "known toolchain profile", such as a Linaro
   toolchain, a Sourcery CodeBench toolchain etc. People using "custom
   toolchain profile" are not affected.

 - The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to
   indicate that the toolchain is already locally available (as
   opposed to having Buildroot download and extract the toolchain)

 - The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his
   toolchain is directly available through the PATH environment
   variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot
   will do something silly (remove the toolchain contents), but that
   are limited to the toolchain itself.

When such conditions are met, Buildroot will run "rm -rf /*" due to
TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty.

This bug does not exist in 2016.05, and appeared in 2016.08 due to
commit a0aa7e0e17.

Commit a0aa7e0e17 removed the assignment
of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as
part of a global cleanup to remove such assignments that supposedly
had become unneeded following a fix of the package infrastructure
(75630eba22: core: do not attempt
downloads with no _VERSION set).

However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even
for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the
following consequences:

 - Buildroot downloads the toolchain tarball (while we're saying the
   toolchain is already available). Not dramatic, but clearly buggy.

 - Buildroot registers a post-extract hook that moves the toolchain
   from its extract directory (output/build/toolchain-external-.../ to
   its final location in host/opt/ext-toolchain/). Before doing this,
   it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which
   should normally be host/opt/ext-toolchain/).

Another mistake that caused the bug is commit
b731dc7bfb ("toolchain-external: make
extraction idempotent"), which introduce the dangerous call "rm -rf
$(var)/*", which can be catastrophic if by mistake $(var) is
empty. Instead, this commit should have just used rm -rf $(var) to
remove the directory instead: it would have failed without consequences
if $(var) is empty, and the directory was anyway already re-created
right after with a mkdir.

To address this problem, we:

 - Revert commit a0aa7e0e17, so that
   _SOURCE and _SITE are empty in the pre-installed toolchain case.

 - Rework the code to ensure that similar problems will no happen in the
   future, by:

   - Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when
     BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is
     only needed when Buildroot downloaded the toolchain.

   - Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which
     is the path in which Buildroot installs external toolchains when it
     is in charge of downloading/extracting them. Then, the
     TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which
     is guaranteed to be non-empty.

   - Replace the removal of the directory contents $(var)/* by removing
     the directory itself $(var). The directory was anyway already
     re-created if needed afterwards. Thanks to doing this, if $(var)
     ever becomes empty, we will do "rm -rf" which will fail and abort
     the build, and not the catastrophic "rm -rf /*".

Reported-by: Mason <slash.tmp@free.fr>
Cc: Mason <slash.tmp@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-15 11:59:07 +02:00
Fabio Estevam
d3ac2bc616 linux-headers: allow specifying 4.8 as kernel header version
Even though 4.8 is not released yet, some people may want to build a
system using the 4.8-rc kernel, and point to the kernel sources as the
kernel headers to use for the toolchain.

In order to make this possible, this commit adds support for specifying
4.8 as the kernel headers version, in both the internal and external
toolchain logic.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
[Thomas: remove support for 4.8 headers selection, and rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-12 22:57:53 +02:00
Gustavo Zacarias
4338a319b7 arch: remove support for sh64
It's been deprecated for quite some time now.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-08 22:15:15 +02:00
Peter Korsgaard
7353967690 Merge branch 'next'
Quite some conflicts, so here goes ..

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-02 16:20:33 +02:00
Waldemar Brodkorb
e732bd1f22 bfin: change default to bf532, internal toolchain !bf6xx
The default Blackfin processor in Buildroot isn't supported by
gcc 6.1.0, so use bf532 as default. Disable any bf6xx processors
for internal toolchain users.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-27 23:07:11 +02:00
Waldemar Brodkorb
721e1c1e9c musl: enable mips64 support
Add support for mips64, which is available since musl 1.1.15.

Only gcc 6.x has required support for it. Tested variations of
little/big endian and hard/soft float.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-22 23:10:09 +02:00
Waldemar Brodkorb
5ab751ca44 toolchain-buildroot: allow to build ppc64(le) musl toolchains
Latest musl release supports ppc64 architecture (both big endian and
little endian), so this commit adds support for this.

Since musl implements the ELFv2 ABI for both big-endian and
little-endian PowerPC64, we have to force using this ABI on PowerPC64
big endian (normally elfv1 is the default).

Also, only gcc 6.x has the necessary changes to support musl on PowerPC
64, so we restrict the gcc version selection accordingly.

Tested with Qemu for big endian and little endian configurations.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: add comment about the ABI flag in gcc.mk, rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-19 14:28:01 +02:00
Yann E. MORIN
e31eb72040 package/musl-compat-headers: provide compatibility headers not in musl
musl provides neither sys/queue.h nor sys/cdefs.h. Those two headers are
however quite widely used in a lot of packages (though they should at
least not use cdefs.h which is only full of mostly-legacy macros, and
which is mostly an internal header of glibc and was never really meant to
be exposed to, and used by packages).

But we don't live in an ideal world, so a lot of packages break when
those two headers are missing.

We already took care of sys/queue.h with the netbsd-queue package. But
the need for cdefs.h is getting more and more pressing.

We rename the netbsd-queue package into musl-compat-headers, and we
make it install sys/queue.h (from NetBSD) and sys/cdefs.h (a minimalist
one we bundle in Buildroot). We can't use the cdefs.h from NetBSD
because it includes machine-dependent headers; instead we bundle a very
minimalistic one, that covers only what we need.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-19 11:29:12 +02:00
Thomas Petazzoni
a77e8d275f system: move locale purging options to the "System configuration" menu
The options to purge locales and to generate locale data are currently
located in the toolchain menu. However, these options are not really
related to the toolchain per-se, they are more system-level
configuration options, much like the timezone selection option we
already have in the "System configuration" menu.

Therefore, it makes more sense to have the locale-related options in
the "System configuration" menu as well.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-03 21:17:21 +02:00
Thomas Petazzoni
6e757a6c5c toolchain: reduce the list of locales to keep by default
Our current list of locales to keep by default is "C en_US de fr". It
doesn't make much sense to keep "de" and "fr" more than any other
language. So let's keep only the "C" and "en_US" locales by default,
and leave it to the user to specify other locales to keep if needed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-03 21:17:13 +02:00
Thomas Petazzoni
284cb4fb2e toolchain: purge locales by default
Our current default is to keep all locales installed in
/usr/share/locale/. However, in practice, those locales take up a
significant amount of space, and most users do not need
locales. Therefore, it makes more sense to default to purging locales,
in order to keep only a few useful ones rather than keeping them all.

It helps in providing a small filesystem size by default, and still
allows advanced users who really need locales to tune their
configuration.

As an example, a very basic system with just util-linux enabled (not
even Busybox) weights 11 MB, including 6.4 MB of locales. With this new
default, the generated system is only 4.2 MB.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-03 21:17:01 +02:00
Romain Naour
b3d1fb26dc toolchain: libatomic is not built on "uclinux" platforms
The cairo package fails to build on some architectures:
BR2_TOOLCHAIN_HAS_LIBATOMIC is enabled, but libatomic is in fact not
available.

This happens because the gcc logic in libatomic/configure.tgt does not
recognize "uclinux" as a valid OS part of the target tuple, and
therefore it does not build libatomic.

The "uclinux" part of the tuple is used by Buildroot when
BR2_BINFMT_FLAT=y, so we make BR2_TOOLCHAIN_HAS_LIBATOMIC enabled only
if !BR2_BINFMT_FLAT.

It is worth mentioning that support for the uclinux tuple could most
likely very easily be added to gcc: it could rely on the generic
"posix" implementation of libatomic, which uses pthread locks,
available on all architectures where thread support is available.

Fixes:

 [arm]  http://autobuild.buildroot.net/results/3d8dc45e41a043d2c2c26bfb26c3617499fbe671
 [m68k] http://autobuild.buildroot.net/results/318e01406e3e92eb589ee5b2231c671a4dbb6da4

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: adjust dependency after analysis of the gcc code.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-02 23:33:46 +02:00
Waldemar Brodkorb
fd00d6d8a4 uclibc: disable PIE for microblaze
PIE is not supported at the moment for uClibc-ng/microblaze.
Fixes:
http://autobuild.buildroot.net/results/a5848753eb0e2b0ddf55e226c45b85fd3a1c84f3/

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-01 23:01:20 +02:00
Vlad Zakharov
3897ded714 toolchain: Bump ARC tools to arc-2016.09-eng007 and enable PIE
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng007 tag plus a
couple of fixes on top of it that will all make its way in the
next engineering build.

We hope this patch will cure most buildroot ARC failures as it
contains important fixes:

1) PIE fix. We have added PIE support to ARC toolchain at last.
So that should prevent breakage of many packages. As ARC now
supports PIE we remove ARC from BR2_TOOLCHAIN_SUPPORTS_PIE
exclusion in toolchain/Config.in file.

2) Assembler fix. This patch also have changes that fixes frequent
assembler failures, e.g.:
http://autobuild.buildroot.net/results/543/5430b902d900943a34c1888e7e410bd5df367bc2//

We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.

So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.

Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
[Thomas: remove uClibc PIE patch, since we have bumped uClibc in the
mean time, to a version that contains the PIE fix for ARC.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-01 22:59:31 +02:00
Thomas Petazzoni
e9f6ef8204 toolchain-external: musl toolchain on ARM is for MMU-systems only
Now that we have introduced the support for ARM no-MMU in Buildroot,
we need to update the dependencies of the musl external toolchain. It
supports only MMU-capable ARM cores, so it must depend on BR2_USE_MMU,
at least for the ARM platforms.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-07-28 22:15:03 +02:00
Thomas Petazzoni
0dc11272f5 toolchain-external: update ARMeb musl dependency
ARM big-endian is different from ARMv4/5/6 and ARMv7. Big-endian on
ARMv4/5/6 is BE-32 while big-endian on ARMv7 is BE-8, which are not
compatible.

Therefore, the musl big endian toolchain that is built for ARMv4
cannot work for ARMv7, it can only work for ARMv4/5/6.

This commit updates the musl toolchain dependency accordingly.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-07-28 22:14:59 +02:00
Fabio Estevam
e36bf63f9f toolchain: add 4.7.x choice for headers
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-25 22:16:59 +02:00
Waldemar Brodkorb
3c93901bcd toolchain: add hidden symbol for PIE support
uClibc-ng does not support PIE for some architectures as
arc and m68k. It isn't implemented in the static linking case, too.
With musl toolchains you might have static PIE support with little
patching of gcc. Static linking for GNU libc isn't enabled in
buildroot. Fixup any package using special treatment of PIE.
(grep -ir pie package/*/*.mk)

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: use positive logic.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-24 21:44:22 +02:00
Yann E. MORIN
fbbd7ce201 toolchain: use the <PKG>_TARGET_FINALIZE_HOOKS
Register toolchain-specific target-finalize hooks with the
newly-introduced <PKG>_TARGET_FINALIZE_HOOKS.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-18 23:30:46 +02:00
Romain Naour
ffafb77da2 toolchain-external: Commonize /lib/<tuple> symlinks for Linaro toolchains
As proposed initialy by Matthew Fornero [1], commonize the creation of
symlinks from {/usr}/lib to {/usr}/lib/<tuple> for Linaro toolchains.

This symlinks are only required for old Linaro toolchains.

[1] http://patchwork.ozlabs.org/patch/624577

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Matthew Fornero <mfornero@mathworks.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-04 17:05:36 +02:00
Vicente Olivert Riera
c1d90e9bb7 toolchain-external: wrap gfortran
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-07-04 14:55:06 +02:00
Vicente Olivert Riera
ddf286736f toolchain-external: bump Codescape toolchains to 2016.05
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-07-04 14:47:42 +02:00
Waldemar Brodkorb
2d6fe1d3ec toolchain-buildroot: add bfin support
With gcc 6.1.0 and binutils 2.26 internal bfin toolchain can be used. A
gcc patch is required, which was reported upstream.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-04 11:00:15 +02:00
Samuel Martin
0175684628 toolchain/toolchain-external: update external toolchains that have Fortran support
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
[Vincent: BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX also has fortran]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:58:11 +02:00
Samuel Martin
a650438d07 toolchain/toolchain-external: add knob for fortran support
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:58:11 +02:00
Samuel Martin
8814d65337 toolchain/toolchain-external: add lib{gfortran,quadmath} to TOOLCHAIN_EXTERNAL_LIBS
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:58:11 +02:00
Samuel Martin
a1922c107b toolchain/toolchain-external: enable fortran check when it is selected
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:58:11 +02:00
Samuel Martin
26db83c8a0 toolchain/helpers: add fortran check
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas: remove extension for the generated temporary file, since it's
really an executable, not an object file.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:58:11 +02:00
Samuel Martin
b8a05376f6 toolchain: add hidden symbol for fortran support in the toolchain
This symbol should be used in all packages requiring/testing for fortran
support.

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:58:11 +02:00
Samuel Martin
b16f8c7876 toolchain/toolchain-common.in: add BR2_TOOLCHAIN_HAS_LIBQUADMATH hidden symbol
This hidden symbol allow to know when libquadmath can be built and
installed.

Also, declaring this symbol in toolchain-common.in allows to use it in
both external and buildroot toolchain backend.

This will be needed for adding/improving the fortran support.

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03 16:58:11 +02:00
Thomas Petazzoni
a0aa7e0e17 toolchain-external: remove SOURCE/SITE for locally available toolchain
When the custom external toolchain is locally available, we currently
define SITE/SOURCE to empty variables. Now that the package
infrastructure doesn't define a value for SOURCE when VERSION is empty,
it doesn't attempt to download a file anymore, so we can get rid of
those empty SOURCE/SITE variables in the toolchain-external package.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-07-03 13:00:25 +02:00
Thomas Petazzoni
416fd9cd13 Replace (e)glibc by glibc
Following the removal of eglibc support, this commit replaces all
occurences of "(e)glibc" by just "glibc". Most of the occurences are in
package Config.in comments.

In addition, when the form "an (e)glibc ..." was used, it is replaced by
"a glibc ...".

[Peter: add new efi* packages, s/uclibc/uClibc as suggested by Romain,
        systemd / liquid-dsp tweaks as suggested by Yann]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-06-28 22:19:22 +02:00
Waldemar Brodkorb
df00b174f6 m68k: gcc coldfire does not provide _sync atomics
Trying to use __sync_fetch_and_add ends with a gcc ICE.
This fixes following autobuild failure, by actually disabling
the package for coldfire:
http://autobuild.buildroot.net/results/d719db11210d42501332586b4485ab0cc1e125dd/

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-06-27 15:06:25 +02:00
Vicente Olivert Riera
2d3625deae toolchain-external: hook for Codescape toolchain side-by-side layout
The Codescape toolchain uses a sysroot layout that places them
side-by-side instead of nested like multilibs. A symlink is needed much
like for the nested sysroots which are handled in copy_toolchain_sysroot
but there is not enough information in there to determine whether the
sysroot layout was nested or side-by-side.

For the above reason plus the fact that this is the only toolchain
needing this, better to handle that symlink creation using a hook which
will be executed only when that toolchain is selected.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-07 23:41:36 +02:00
Vicente Olivert Riera
7b6cfca130 Revert "toolchain: allow side by side sysroot directories"
This reverts commit 9a1e9efe26.

Currently Codescape toolchains cannot be used to generate a big endian
root file system because the support for side by side sysroots is not
complete.

There is a patch [1] waiting in the queue which fixes the issue for the
current version of Codescape toolchains we have, but it will not work
for the next one that is coming. So, instead of messing more with the
toolchain infra I think it's better to handle these specific Codescape
toolchain's weirdness in hooks which won't affect others.

[1]: http://patchwork.ozlabs.org/patch/571708/

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-07 23:27:10 +02:00
Waldemar Brodkorb
7dcec609ee uclibc: the internal toolchain only uses uClibc-ng
Point to the right website and tell the user the right name.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-06 22:26:08 +02:00
Waldemar Brodkorb
843fc19259 uclibc: add microblaze support
Latest uClibc-ng 1.0.15 release fixed open issues with
microblaze shared library and linuxthreads support.
gcc 4.9.3 and gcc 5.3.0 require a small patch.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-06-05 22:16:45 +02:00
Peter Korsgaard
577021e81b Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-06-01 17:55:16 +02:00
Yann E. MORIN
49648d4b01 toolchain/helper: don't follow symlinks when copying libs to target
In 2a87b64 (toolchain-external: align library locations in target and
staging dir), copying the libraries from the sysroot to the target was
changed to a simple find-based solution.

To be sure that the staging directory was entered to find the libraries,
in case the variable was pointing to a symlink, the -L clause to find
was used.

However, that causes extraneous libraries to be copied over.

For example, a ct-ng toolchain would have this sysroot (e.g for an arm
32-bit toolchain):

    .../sysroot/lib/
    .../sysroot/lib32 -> lib
    .../sysroot/lib64 -> lib
    .../sysroot/usr/lib/
    .../sysroot/usr/lib32 -> lib
    .../sysroot/usr/lib64 -> lib

Which we would carry as-is to our own sysroot.

But then, in target, our skeleton creates the /lib/ and /usr/lib
directories, with the necessary lib32 or lib64 symlink pointing to it.
In this case, a lib32->lib symlink is created, but no lib64 symlink
since this is a 32-bit architecture.

To copy the required libraries from staging into target, we scan the
staging directory for all occurences of the required libraries, and copy
them over to target, keeping the same directory layout relative to the
sysroot.

For example:
    .../sysroot/usr/lib/libfoo.so   -->  .../target/usr/lib/libfoo.so
    .../sysroot/usr/lib32/libbar.so -->  .../target/usr/lib32/libbar.so
    .../sysroot/usr/lib64/libbuz.so -->  .../target/usr/lib64/libbuz.so

So, when we copy over the libraries from our staging to the target
directory, the "find -L .../sysroot -name libblabla.so.*" would find
multiple instances of libblabla, each in the /usr/lib /usr/lib32 and
/usr/lib64 locations (they are all the exact same file, though).

Since we do have the /usr/lib32->lib symlink, all is OK (but there are
two copies going on, which could be avoided). However, since we do not
have the /usr/lib64->lib symlink, the /usr/lib64/ directory is created.

This was very difficult to observe, as no /lib64/ directory is created,
only the /usr/lib64/ one was. To top it off, this only happens with a
merged /usr, which does not seem like not a common case without systemd.

Since the reason to use -L was to be sure to enter our staging
directory, we just need to ensure that the path ends up with a slash, as
was already talked about in this thread:
    http://lists.busybox.net/pipermail/buildroot/2016-April/159737.html

After further discussion, it turns out that the original patch came along
because of the confusion between output/staging (which is a symlink) and
$(STAGING_DIR) which expands to output/host/usr/<tupple>/sysroot (which is
never a symlink), so the symlink handling isn't really needed at all.

[Peter: drop description comment, extend description]
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>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-30 22:53:54 +02:00
Clayton Shotwell
9891e5cbfa toolchain-external: correct hash value for Linaro AArch64 toolchain source
The aarch64 Linaro toolchain source hash is not correct, probably due
to a copy/paste error. The new hash has been verified by downloading
the tarball, validating the signature, and computing the hash.

Signed-off-by: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-24 17:32:47 +02:00
Vicente Olivert Riera
794935068b toolchain: improve SSP logic
Don't enable SSP support on external toolchains just because they use
glibc or musl. Instead of that, make the external toolchains explictily
declare if they support SSP or not. And also add a check to detect SSP
support when using custom external toolchains.

For internal toolchains we always enable SSP support for glibc and musl.

Fixes:

  http://autobuild.buildroot.net/results/ac7c9b3ad2e52abfe6b79a80045e4218eeb87175/

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas:
 - remove uClibc-specific SSP check, since there is now a generic
   check being done.
 - send potential compilation errors caused by the SSP check to
   oblivion, in order to avoid causing confusion for the user.
 - add autobuilder reference.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-23 21:07:24 +02:00
Romain Naour
04c9d65039 toolchain-external: bump CodeSourcery NIOSII to 2016.05
The toolchain still use binutils 2.25 without the fix for PR19405.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-23 17:36:11 +02:00
Thomas Petazzoni
a8e6f52f0c toolchain: musl support is no longer experimental
Our musl support has now been around for quite some time, numerous
packages have been fixed (although admittedly not all). It's time to no
longer call our musl support "experimental": things are now expected to
be working with musl just like with the other two C libraries we
support.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-17 08:53:12 +02:00
Thomas Petazzoni
500de2598a toolchain: remove eglibc support
The eglibc support has been marked deprecated since 2015.08, so it's
time to remove it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-17 08:48:23 +02:00
Gustavo Zacarias
51800d20b9 toolchain: add 4.6.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-16 21:15:18 +02:00
Romain Naour
8389b62352 toolchain-external: fix user provided libraries deployment
In commit 919b4f9eab the internal symbol
LIB_EXTERNAL_LIBS was renamed TOOLCHAIN_EXTERNAL_LIBS but the find and
replace command also renamed BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS to
BR2_TOOLCHAIN_EXTRA_TOOLCHAIN_EXTERNAL_LIBS which doesn't exist.

So user provided libraries defined in BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS
are not copied anymore to staging and target directories.

For example:
BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS="libasan.* libubsan.*"

Simply revert this change by renaming
BR2_TOOLCHAIN_EXTRA_TOOLCHAIN_EXTERNAL_LIBS to BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-13 15:05:25 +02:00
Thomas Petazzoni
60b843edf0 toolchain-external: fix registration of hook for Sourcery Aarch64 toolchain
As noticed by Romain Naour, commit
4d39ca1c2a ("toolchain-external: fix
installation for CodeSourcery AArch64 toolchain") has a small bug where
a post-install hook doing fixups in TARGET_DIR was registered as a
staging installation hook while it should have been registered as a
target installation hook. This commit fixes this inconsistency.

Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-08 15:05:14 +02:00
Gustavo Zacarias
8490e8333d toolchain-external: remove Sourcery PowerPC toolchains
These are running long on the teeth - the bundled (e)glibc versions
are very old with several security bugs, they don't work reliably with
-Os and have several build failures related to internal compiler
errors such as:

http://autobuild.buildroot.net/results/fe7/fe7bdba5faf199275aedea2918705b5d19d228bf/
http://autobuild.buildroot.net/results/935/935ac42c30ed893939c06c077534f060aed80e9a/
http://autobuild.buildroot.net/results/a47/a476af82c8fe4a279117314b278b08af9a08fe54/
http://autobuild.buildroot.net/results/cae/cae720b5096be2672b4dc1311ae3fc4ed06a3b53/

The situation will not provide, and will in fact get worse with older kernel
headers precluding modern package versions and the old gcc version doing as
well so remove them.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
 - remove no longer needed comment in liquid-dsp Config.in file, as
   noticed by Romain Naour.
 - add Config.in.legacy options, as noticed by Romain Naour.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 15:05:34 +02:00
Romain Naour
230cfce93d toolchain-external: bump CodeSourcery MIPS to 2016.06-8
Add hash for the toolchain sources.

Runtime tested with Qemu with qemu_mips_malta_defconfig

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 14:56:06 +02:00
Romain Naour
14a75e09b9 toolchain-external: bump CodeSourcery AMD64 to 2015.11-139
>From getting-started.pdf:
- Linker bug fix.
- Fix CVE 2015-7547 getaddrinfo.
- Breakpoint in non-existent file bug fix.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 14:46:17 +02:00
Romain Naour
8ed38d8b4b toolchain-external: bump CodeSourcery NiosII to 2015.11-130
>From getting-started.pdf:
- DWARF signed LEB128 encoding fix
- Fix CVE 2015-7547 getaddrinfo
- Breakpoint in non-existent file bug fix

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 14:46:06 +02:00
Jörg Krause
8f972c2aed toolchain-external: add GCC 6.x option
Commit 519d83bfa0 adds support for GCC
6. Add an GCC 6.x option for external toolchains, too.

Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 14:41:47 +02:00
Thomas Petazzoni
31d1df0c7c toolchain-external: bump version of Linaro AArch64 toolchain
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 21:10:36 +02:00
Thomas Petazzoni
df4f64c77c toolchain-external: bump version of Linaro ARMeb toolchain
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 21:10:35 +02:00
Thomas Petazzoni
292fa50452 toolchain-external: bump version of Linaro ARM toolchain
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 21:10:34 +02:00
Romain Naour
e7a682be31 toolchain-external: bump CodeSourcery aarch64 to 2014.11
Runtime tested using qemu_aarch64_virt_defconfig.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas: updated to the latest master branch.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 18:19:46 +02:00
Romain Naour
4d39ca1c2a toolchain-external: fix installation for CodeSourcery AArch64 toolchain
The extracted toolchain sources contains a single symlink in the
aarch64-linux-gnu/libc/lib directory wich is lost during Buildroot's
staging install.

aarch64-linux-gnu/libc/lib/ld-linux-aarch64.so.1 -> ../lib64/ld-2.18.so

Add a custom post install staging and target hooks to create it
manually.

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: also make the same tweak in the target.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 15:41:40 +02:00
Thomas Petazzoni
519d83bfa0 gcc: add support for gcc 6
This commit adds the support for gcc 6. This release allows to remove
a large number of our gcc patches, mainly thanks to the Xtensa and
musl related patches being merged upstream.

Patches kept with no changes:

 100-uclibc-conf.patch
 301-missing-execinfo_h.patch
 810-arm-softfloat-libgcc.patch
 830-arm_unbreak_armv4t.patch
 840-microblaze-enable-dwarf-eh-support.patch
 860-cilk-wchar.patch
 890-fix-m68k-compile.patch

Patches dropped because they have been merged upstream, or were
already upstream backports:

 120-gcc-config.gcc-fix-typo-for-powerpc-e6500-cpu_is_64b.patch (merged)
 850-libstdcxx-uclibc-c99.patch (merged in a different form, see
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393)
 870-xtensa-add-mauto-litpools-option.patch (upstream backport)
 871-xtensa-reimplement-register-spilling.patch (upstream backport)
 872-xtensa-use-unwind-dw2-fde-dip-instead-of-unwind-dw2-.patch (upstream backport)
 873-xtensa-fix-_Unwind_GetCFA.patch (upstream backport)
 874-xtensa-add-uclinux-support.patch (upstream backport)
 900-libitm-fixes-for-musl-support.patch (upstream backport)
 901-fixincludes-update-for-musl-support.patch (upstream backport)
 902-unwind-fix-for-musl.patch (upstream backport)
 903-libstdc++-libgfortran-gthr-workaround-for-musl.patch (upstream backport)
 904-musl-libc-config.patch (upstream backport)
 905-add-musl-support-to-gcc.patch (upstream backport)
 905-add-musl-support-to-gcc.patch (upstream backport)
 906-mips-musl-support.patch (upstream backport)
 907-x86-musl-support.patch (upstream backport)
 908-arm-musl-support.patch (upstream backport)
 909-aarch64-musl-support.patch (upstream backport)

Successfully build-time and run-time tested with
qemu_arm_vexpress_defconfig, using gcc 6.x, both in uClibc and musl
configurations.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-04-27 23:11:53 +02:00
Romain Naour
4b201090d8 toolchain/helper: update check_unusable_toolchain comment
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-27 22:19:19 +02:00
Romain Naour
6bb0355300 toolchain-external: move the sysroot check to helper function
The sysroot toolchain support check is duplicated at two locations in
the external toolchain infra. So move it inside the
check_unusable_toolchain helper that is called when the toolchain
package is configured (TOOLCHAIN_EXTERNAL_CONFIGURE_CMDS).

The check in TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS can be safely
removed since it's already done in check_unusable_toolchain helper.

The check in TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS was removed by
2a87b64f8e.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-27 22:18:35 +02:00
Romain Naour
c32c390e13 toolchain-external: add a check for unsupported toolchains
Some toolchain can't be used by Buildroot due to sysroot location
issue, so the $(ARCH)-linux-gnu-gcc -print-file-name=libc.a command
return only "libc.a"

This lead to an error during the header check version helper,
so these toolchains can't be imported into Buildroot.

cc1: fatal error: $PWD/libc.a/usr/include/linux/version.h: No such file or directory
compilation terminated.
support/scripts/check-kernel-headers.sh: line 38: /tmp/check-headers.4V5PPF: Permission denied

This issue happen with the first linaro 2015.11 [1] release and
CodeSourcery standard edition [2].

Here is the sysroot directory tree for linaro 2015.11:
$ ls libc/arm-linux-gnueabihf
etc  lib  sbin  usr  var

Here is the sysroot directory tree for CodeSourcery standard:
$ ls libc/sgxx-glibc
etc  lib  lib64  sbin  usr  var

Add a check to error out with an explicit error message

The check don't use toolchain_find_libc_a function directly since
"realpath -f" is used internally and return an absolute path.

[1] https://bugs.linaro.org/show_bug.cgi?id=1995#c7
[2] http://lists.busybox.net/pipermail/buildroot/2014-October/110696.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-27 22:18:05 +02:00
Thomas Petazzoni
ed2a15b791 toolchain-external: remove useless shell continuations
When a message with MESSAGE, we can print it as the first command of
the command sequence, and in this case, we don't need to use a shell
continuation.

In one case, the call to MESSAGE is moved a few lines up in the
sequence of commands.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:55:29 +02:00
Thomas Petazzoni
12584c2c70 toolchain-external: rename Blackfin related special variables
As suggested by Arnout, this commit renames:

 - TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FDPIC to
   TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FDPIC

 - TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FLAT to
   TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FLAT

Which makes it clear that those variables are installing libraries to
the target, and make their naming more consistent with the naming of
other variables in the file.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:48:58 +02:00
Thomas De Schampheleire
919b4f9eab toolchain-external: unify LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS
With the alignment of toolchain library location in target and staging,
there is no need anymore for the distinction between LIB_EXTERNAL_LIBS and
USR_LIB_EXTERNAL_LIBS. Unify them into TOOLCHAIN_EXTERNAL_LIBS.

Related, update the help text of
BR2_TOOLCHAIN_EXTRA_TOOLCHAIN_EXTERNAL_LIBS.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:48:56 +02:00
Thomas De Schampheleire
2a87b64f8e toolchain-external: align library locations in target and staging dir
The toolchain-external logic is roughly:
- populate the staging dir by rsyncing the entire ${ARCH_LIB_DIR} and
  usr/${ARCH_LIB_DIR} from sysroot.
- populate the target dir by explictly copying some libraries from sysroot
  into target/lib and some other libraries in target/usr/lib, the split
  being hardcoded into buildroot regardless of the location in the sysroot.

This means that a library libfoo could be located in:
  staging/lib/libfoo.so
  target/usr/lib/libfoo.so

When debugging an application that links against this library, gdb will
fruitlessly search for 'usr/lib/libfoo.so' in staging, and then suggest to
use 'set solib-search-path' which is a hack, really.

To solve the problem, we need to make sure that libraries from the toolchain
are installed in the same relative location in staging and target.
Achieve this by:
- replacing the convoluted search for libraries using for+find in sysroot
  with a simple find in staging.
- determining DESTDIR for each library individually based on the location in
  staging.
- treating LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS equivalently

These changes also allow for the removal of most arguments to
copy_toolchain_lib_root in the method itself and their callers.

Test procedure:
- set configuration for a given toolchain
- make clean toolchain
- find output/target | sort > /tmp/out-before
- apply patch
- make clean toolchain
- find output/target | sort > /tmp/out-after
- diff -u /tmp/out-before /tmp/out-after

The only changes should be some libraries moving from lib to usr/lib or vice
versa. Notable examples being libstdc++ and libatomic.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas:
 - use -L instead of -follow in the find invocation, as suggested by
   Arnout.
 - move the BR2_STATIC_LIBS condition as a make condition rather than
   a shell condition, as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:46:28 +02:00
Thomas De Schampheleire
10e905f83d toolchain-external: extract installation of gdbserver to separate define
The installation of the gdbserver binary has no relation to the installation
of the target libraries. Moving it to a separate define improves the
understandability of the code and makes later refactoring easier.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[Thomas:
 - move the BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY condition as a make
   condition rather than a shell condition, as suggested by Romain
   Naour.
 - rename the TOOLCHAIN_EXTERNAL_INSTALL_GDBSERVER variable to
   TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:05:45 +02:00
Thomas De Schampheleire
38040b2e1f toolchain-external: blackfin: install FDPIC libraries also to staging
For external Blackfin toolchains with BR2_BFIN_INSTALL_FDPIC_SHARED set,
the FDPIC shared libraries are currently only copied to the target
directory, not to staging.

For debugging purposes, an unstripped copy in staging is necessary.
Moreover, this change will simplify a subsequent change that lines up the
location of shared libraries between target and staging directories.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 21:56:34 +02:00
Thomas De Schampheleire
4896b7c96f toolchain-external: remove unused calculation of ARCH_SUBDIR
In TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS, ARCH_SUBDIR is calculated but not
used, and can thus be removed. Since SYSROOT_DIR is only used for the
calculation of ARCH_SUBDIR, it can be removed too.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-21 23:30:20 +02:00
Romain Naour
5dce3c05b5 toolchain-external: CodeSourcery NiosII 2015.11 affected by PR19405
See bug report https://sourceware.org/bugzilla/show_bug.cgi?id=19405

Fixes:
http://autobuild.buildroot.net/results/ee562524c5b12191e584ceae89006c5a5103e700

Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
 - rename BR2_TOOLCHAIN_BINUTILS_HAS_BUG_19405 to
   BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405
 - propagate to the qwt package, which is now selecting
   BR2_PACKAGE_QT_GUI_MODULE.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-20 23:20:58 +02:00
Thomas Petazzoni
6cb4814c87 arch/x86: remove support for i386
The Linux kernel doesn't even support i386 anymore, there is no NPTL
support for i386 and uClibc-ng only supports NPTL on x86, so there is
essentially no usable thread implementation. Most likely glibc and
musl also don't support i386 either. So it's time to remove the
support for this architecture variant.

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>
2016-04-18 23:38:34 +02:00
Thomas Petazzoni
ee47352920 toolchain-buildroot: don't show musl on noMMU platforms
While musl has recently gained noMMU support for the sh2 platform, we
don't support this yet. So for the time being, let's not show musl as
an available C library on noMMU platforms. This is for example
important on ARM noMMU: ARM is supported by musl, but not its noMMU
variants.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-04-08 12:09:52 +02:00
Thomas Petazzoni
c6724b4f47 toolchain-buildroot: update glibc comment for noMMU
glibc is not available for noMMU platforms, so it doesn't make sense
to show the comment about glibc requiring dynamic libraries on noMMU
platforms.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-04-08 12:09:28 +02:00
Thomas Petazzoni
4f90f55dc4 toolchain-external: fix getent installation with Codescape MIPS toolchains
When a toolchain is glibc based, the getent package assumes that
$(STAGING_DIR)/usr/bin contains the getent program. Unfortunately, the
Codescape MIPS toolchains do not conform with this:
$(STAGING_DIR)/usr/{bin,sbin} are empty, and instead three directories
are provided: bin-o32, bin-n32 and bin-n64 (ditto for sbin), one for
each supported MIPS ABI.

Since this is a toolchain-specific oddity, we handle it by adding a
post-install fixup hook that creates $(STAGING_DIR)/usr/{bin,sbin} as
symbolic link to the appropriate directory.

Fixes:

   http://autobuild.buildroot.org/results/9c0ee836021553319f166f9de88750535aee0a58/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-30 18:10:16 +02:00
Thomas Petazzoni
42735cb9b9 toolchain: introduce BR2_TOOLCHAIN_HAS_LIBATOMIC
Until now, we were assuming that whenever you have gcc 4.8, libatomic
is available. It turns out that this is not correct, since libatomic
will not be available if thread support is disabled in the toolchain.

Therefore, __atomic_*() intrinsics may not be available even if the
toolchain uses gcc 4.8.

To solve this problem, we introduce a BR2_TOOLCHAIN_HAS_LIBATOMIC
boolean, which indicates whether the toolchain has libatomic. It is
the case when you are using gcc >= 4.8 *and* thread support is
enabled. We then use this new BR2_TOOLCHAIN_HAS_LIBATOMIC to define
BR2_TOOLCHAIN_HAS_ATOMIC.

As explained in the comment, on certain architectures, libatomic is
technically not needed to provide the __atomic_*() intrinsics since
they might be all built-in. However, since libatomic is only absent in
non-thread capable toolchains, it is not worth making things more
complex for such seldomly used configuration.

Note that we are introducing the intermediate
BR2_TOOLCHAIN_HAS_LIBATOMIC option because it will be useful on its
own for certain packages.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: improve Config.in comment using a suggestion from Yann.]
2016-03-20 23:40:03 +01:00
Yann E. MORIN
5b96eb6703 toolchain/external: add hashes for actual sources
As we currently download the actual sources as part of saving the
legal-info, we do not check the hashes of those downloads.

That's because, during legal-info, there is not package involved, and
thus there's no path to an actual .hash file.

However, this precludes legal-info from working in off-line mode. A
subsequent patch will make it possible to do so, and actual sources will
be downloaded as another classical package download.

This will have two consequences:

  - first, we will be able to add hashes for actual sources, so we can
    ensure their integrity,

  - second, and as a direct consequence of the above, when a .hash file
    is present, it would have to list all the hashes for that package,
    or that would be treated as an error.

Currently, the only package that falls in this case is the external-
toolchain, for which we have means to retrieve the sources for some of
the toolchains.

So we just add hashes for those actual external-toolchain sources we may
have to download.

Those hashes are not used for now, but they'll come into play a few
patches down.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-19 15:10:18 +01:00
Gustavo Zacarias
3ece3faafa toolchain: add 4.5.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-14 13:11:59 +01:00
Jason Abele
ddd87a7e0b toolchain: switch linaro to https urls
Signed-off-by: Jason Abele <jason@nextthing.co>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-09 22:59:31 +01:00
Yann E. MORIN
6c294b83db toolchain: also source the musl package
We do source the glibc and uClibc packages in the toolchain menu,
because they do provide user-visible options. However, we do not so
far source the musl Config.in file

However, in 822be87 (toolchain: include C libraries in legal-info),
a Config.in file for musl was explicitly created, so that:
  - legal-info would work (needed at the time, probably no longer needed
    nowadays),
  - the appropriate packages are enabled, like netbsd-queue or kernel
    headers.

Yet, we do not source musl/Config.in, which means we do not get
netbsd-queue or kernel-headers to be selected:

    $ make distclean; make menuconfig
        Toolchain  --->
          C library ---> musl
      save-and-exit
    $ grep BR2_PACKAGE_LINUX_HEADERS .config
        [nothing]
    $ grep BR2_PACKAGE_NETBSD_QUEUE .config
        [nothing]

Fix that by sourcing musl/Config.in at the same place we source glibc
and uClibc.

Normally, we do have a check in place that verifies that a package
that is not enabled is not a dependency of another package that is
enabled. However, musl is only a dependency of host-gcc-final, which
is a host package and has no corresponding BR2_PACKAGE_HOST_GCC_FINAL.
Thus host-gcc-final is not in the PACKAGES variable, and thus does not
trigger our check.

Reported-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
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>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-08 21:59:40 +01:00
Vicente Olivert Riera
2b3fa6b4b7 toolchain: bump Codescape toolchains to version 2015.10
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-08 21:02:16 +01:00
Thomas Petazzoni
df4d908ed5 toolchain-external: bump musl toolchain to 1.1.12
While the prebuilt musl toolchains provided by http://musl.codu.org/
had not been updated in a while, a new release based on musl 1.1.12
has been put online in December 2015. This commit updates our external
toolchain package to use this new pre-built toolchain.

Compared to the previous 1.1.6 toolchain, there are some changes:

 - The MIPS big endian soft-float variant is no longer available.
 - The Microblaze variant is no longer available.
 - SuperH 4, both little and big endian, variants have been added.
 - The components have been updated: gcc 5.3 is used, binutils 2.25.1,
   and of course musl 1.1.12.

Besides the update itself, in this commit, we are:

 - Making the musl toolchain non-selectable on MIPS big endian
   soft-float.

 - Making the musl toolchain actually work on MIPS little endian
   soft-float, by downloading the right tarball and setting up the
   right symbolic link.

 - Removing support for the Microblaze variant, and adding support for
   the SH4 variants.

All variants except armeb have been boot tested under Qemu, up to a
Busybox shell prompt. armeb has not been tested due to the lack of a
Qemu configuration for this architecture.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-05 15:54:35 +01:00
Peter Korsgaard
28cd1ed30a Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-02 21:25:00 +01:00
Gustavo Zacarias
2b9a7128e7 glibc: remove version 2.21
Mask out glibc for sparc as well since it's no longer available.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-29 22:57:26 +01:00
Peter Korsgaard
c0c3d7d6c9 toolchain-external/Config.in: Fix Linaro typo
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-21 22:19:54 +01:00
Thomas Petazzoni
6856e417da toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleans
Currently, Buildroot provides one BR2_ARCH_HAS_ATOMICS boolean option
to indicate whether the architecture supports atomic operations or
not. However, the reality of atomic operations support is much more
complicated and requires more than one option to be expressed
properly.

There are in fact two types of atomic built-ins provided by gcc:

 (1) The __sync_*() family of functions, which have been in gcc for a
     long time (probably gcc 4.1). They are available in variants
     operating on 1-byte, 2-byte, 4-byte and 8-byte integers. Some
     architectures implement a number of variants, some do not
     implement any, some implement all of them.

     They are now considered "legacy" by the gcc developers but are
     nonetheless still being used by a significant number of userspace
     libraries and applications.

     https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html

 (2) The __atomic_*() family of functions, which have been introduced
     in gcc 4.7. They have been introduced in order to support C++11
     atomic operations. In gcc 4.8, they are available on all
     architectures, either built-in or in the libatomic library part
     of the gcc runtime (in which case the application needs to be
     linked with -latomic). In gcc 4.7, the __atomic_*() intrinsics
     are only supported on certain architectures, since libatomic did
     not exist at the time.

For (1), a single BR2_ARCH_HAS_ATOMICS is not sufficient, because
depending on the architecture, some variants may or may not be
available. Setting BR2_ARCH_HAS_ATOMICS to false as soon as one of the
variant is missing would cause a large number of packages to become
unavailable, even if they in fact use only more common variants
available on a large number of architectures. For this reason, we've
chosen to introduce four new Config.in options:

 - BR2_TOOLCHAIN_HAS_SYNC_1
 - BR2_TOOLCHAIN_HAS_SYNC_2
 - BR2_TOOLCHAIN_HAS_SYNC_3
 - BR2_TOOLCHAIN_HAS_SYNC_4

Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte
and 8-byte __sync_*() built-ins respectively.

For (2), we introduce a BR2_TOOLCHAIN_HAS_ATOMIC, which indicates if
the __atomic_*() built-ins are available. Note that it is up to the
package to link with -latomic when gcc is >= 4.8. Since __atomic_*()
intrinsics for all sizes are supported starting

We conducted a fairly large analysis about various architectures
supported by Buildroot, as well as with a number of different
toolchains, to check which combinations support which variant. To do,
we linked the following program with various toolchains:

int main(void)
{
	uint8_t a;
	uint16_t b;
	uint32_t c;
	uint64_t d;

	__sync_fetch_and_add(&a, 3);
	__sync_fetch_and_add(&b, 3);
	__sync_fetch_and_add(&c, 3);
	__sync_fetch_and_add(&d, 3);

	__sync_val_compare_and_swap(&a, 1, 2);
	__sync_val_compare_and_swap(&b, 1, 2);
	__sync_val_compare_and_swap(&c, 1, 2);
	__sync_val_compare_and_swap(&d, 1, 2);

	__atomic_add_fetch(&a, 3, __ATOMIC_RELAXED);
	__atomic_add_fetch(&b, 3, __ATOMIC_RELAXED);
	__atomic_add_fetch(&c, 3, __ATOMIC_RELAXED);
	__atomic_add_fetch(&d, 3, __ATOMIC_RELAXED);

	__atomic_compare_exchange_n(&a, &a, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
	__atomic_compare_exchange_n(&b, &b, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
	__atomic_compare_exchange_n(&c, &c, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
	__atomic_compare_exchange_n(&d, &d, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);

	return 0;
}

And looked at which symbols were unresolved. For the __atomic_*()
ones, we tested with and without -latomic to see which variants are
built-in, which variants require libatomic. This testing effort has
led to the following results:

                __sync       __atomic    gcc
               1  2  4  8    1  2  4  8
ARC            Y  Y  Y  -    Y  Y  Y  L   4.8 [with BR2_ARC_ATOMIC_EXT]
ARC            -  -  -  -    L  L  L  L   4.8 [without BR2_ARC_ATOMIC_EXT]
ARM            Y  Y  Y  X    Y  Y  Y  Y   4.8, 4.7
ARM            Y  Y  Y  -                 4.5
AArch64        Y  Y  Y  Y    Y  Y  Y  Y   4.9, 5.1
Bfin           -  -  Y  -                 4.3
i386 (i386)    -  -  -  -    L  L  L  L   4.9
i386 (i486..)  Y  Y  Y  -    L  L  L  L   4.9 [i486, c3, winchip2, winchip-c6]
i386 (> i586)  Y  Y  Y  Y    L  L  L  L   4.9
Microblaze     -  -  Y  -    L  L  Y  L   4.9
MIPS           Y  Y  Y  -    Y  Y  Y  L   4.9
MIPS64         Y  Y  Y  Y    Y  Y  Y  Y   4.9
NIOS 2         Y  Y  Y  -    Y  Y  Y  L   4.9, 5.2
PowerPC        Y  Y  Y  -    Y  Y  Y  L   4.9
SuperH         Y  Y  Y  -    Y  Y  Y  L   4.9
SPARC          -  -  -  -    L  L  L  L   4.9
SPARC64        Y  Y  Y  Y    Y  Y  Y  Y   4.9
x86_64         Y  Y  Y  Y    Y  Y  Y  Y   4.7, 4.9
Xtensa         Y  Y  Y  -    Y  Y  Y  Y   4.9

Notes:

 * __atomic built-ins appeared in gcc 4.7, so for toolchais older than
   that, the __atomic column is empty.

 * Y means 'supported built-in'

 * L means 'supported via linking to libatomic' (only for __atomic
   functions)

 * X indicates a very special case for 8 bytes __sync built-ins on
   ARM. On ARMv7, there is no problem, starting from gcc 4.7, the
   __sync built-in for 8 bytes integers is implemented, fully in
   userspace. For cores < ARMv7, doing a 8 bytes atomic operation
   requires help from the kernel. Unfortunately, the libgcc code
   implementing this uses the __write() function to display an error,
   and this function is internal to glibc. Therefore, if you're using
   glibc everything is fine, but if you're using uClibc or musl, you
   cannot link an application that uses 8 bytes __sync
   operations. This has been fixed as part of gcc PR68095, merged in
   the gcc 5 branch but not yet part of any gcc release.

 * - means not supported

This commit only introduces the new options. Follow-up commits will
progressively change the packages using BR2_ARCH_HAS_ATOMICS to use
the appropriate BR2_TOOLCHAIN_HAS_SYNC_x or BR2_TOOLCHAIN_HAS_ATOMIC
until the point where BR2_ARCH_HAS_ATOMICS can be removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-06 11:16:00 +01:00
Yann E. MORIN
e6d1a2073b toolchain/external: newer Linaro toolchains do not provide source code
Currently, we have a pattern-matching that automatically derives the
the source tarball filename from the binary tarball filename.

However, the latest Linaro toolchains no longer follow that scheme (and
do not even readily provide the sources...).

Remove the generic pattern-matching, and explicitly set the source
tarball name for those toolchains that do have a source tarball readily
available.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-03 23:46:27 +01:00
Thomas De Schampheleire
335f331ff2 toolchain: copy_toolchain_lib_root: rename LIBSPATH to LIBPATHS
LIBSPATH is populated based on a find with a pattern that can look like:
    libfoo*.so
and thus the output of the find will contain all file paths that match this
pattern.

Unfortunately, the name LIBSPATH suggests that only one entry is returned,
rather than possibly multiple.

As this code is quite complex, use the more accurate name LIBPATHS iso
LIBSPATH.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-03 23:46:00 +01:00
Romain Naour
2956afbdbc toolchain-external: bump Linaro ARMEB to 2015.11-2
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: only add the symlink with the old 2014.09 Linaro toolchain,
for the newer ones, it is no longer needed.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-01 19:38:02 +01:00
Romain Naour
7199d7a9df toolchain-external: bump Linaro ARM to 2015.11-2
Runtime tested with Qemu 2.3.1 using a configuration based on
qemu_arm_vexpress_defconfig with BR2_ARM_ENABLE_VFP and
BR2_ARM_EABIHF selected

Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: only add the symlink with the old 2014.09 Linaro toolchain,
for the newer ones, it is no longer needed. This has been runtime
tested in Qemu.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-01 19:38:02 +01:00
Romain Naour
711c038715 toolchain-external: bump Linaro AArch64 to 2015.11-2
Runtime tested with Qemu 2.3.1 using qemu_aarch64_virt_defconfig.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: only add the symlink with the old 2014.09 Linaro toolchain,
for the newer ones, it is no longer needed. This has been runtime
tested in Qemu.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-01 19:27:29 +01:00
Thomas De Schampheleire
cef3cd40b7 toolchain-external: create symlink ARCH_LIB_DIR->lib
Currently, following symbolic links are created in both target and
staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> lib

The decision for lib32 or lib64 is based on the target architecture
configuration in buildroot (BR2_ARCH_IS_64).

In at least one case this is not correct: when building for a Cavium Octeon
III processor using the toolchain from the Cavium Networks SDK, and
specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, libraries are expected
in directory 'lib32-fp' rather than 'lib32' (ABI=n32; likewise for
lib64-fp in case of ABI=n64)

More generally the correct symbolic link is from (usr/)${ARCH_LIB_DIR}->lib.
However, feedback from Arnout Vandecappelle is that there are packages that
do depend on the lib32/lib64 symlink, even if ARCH_LIB_DIR is different.
Hence, these links must be kept.

Fix the problem as follows:
- For internal toolchains: no change
- For external toolchains: create a symlink ARCH_LIB_DIR->lib if
  (usr/)ARCH_LIB_DIR does not exist yet.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: "Yann E. Morin" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-01 14:20:10 +01:00
Thomas De Schampheleire
fe23cb5d00 toolchain-external: improve sysroot rsync if ARCH_LIB_DIR != lib/lib32/lib64
The copy_toolchain_sysroot helper in toolchain/helpers.mk performs an
rsync of various directories from the extracted external toolchain to the
corresponding directory in staging.

The relevant (simplified) snippet is:
	for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
		rsync -au --chmod=u=rwX,go=rX --exclude 'usr/lib/locale' \
			--exclude '/lib/' --exclude '/lib32/' \
			--exclude '/lib64/' \
			$${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \
	done ; \

The exclusion logic of lib/lib32/lib64 has originally been added by commit
5628776c4a with the purpose of only copying
the relevant usr/lib* directory from the toolchain to staging, instead of
all. For example, if ARCH_LIB_DIR is 'lib64', then only usr/lib64 would be
copied and usr/lib and usr/lib32 are ignored. It works by ignoring any
lib/lib32/lib64 subdirectory on the rsync of 'usr' and then separately
copying usr/{lib,lib32,lib64} as appropriate. (The exclusion rules only have
impact on the files beneath the main source directory.)

However, ARCH_LIB_DIR can take other values than (lib, lib32, lib64), for
example lib32-fp or lib64-fp (Octeon III toolchain with -march=octeon3). In
the existing code, the rsync for 'usr' would then already copy these lib
directories, and the next rsync for 'usr/$${ARCH_LIB_DIR}' does nothing.

By itself, this is not a very big problem: the staging directory simply has
some extra directories. However, a subsequent patch will create a staging
symlink from $${ARCH_LIB_DIR} to lib. The first rsync would then overwrite
that symlink with the real directory usr/$${ARCH_LIB_DIR} from the
toolchain, which is not correct.

Assuming the patch that creates the symlink ARCH_LIB_DIR->lib is applied,
the original situation after 'make clean toolchain' with an
ARCH_LIB_DIR=lib32-fp is:

$ ls -ld output/staging/{,usr/}lib* output/target/{usr/,}lib*
drwxr-xr-x 2  4096 May 26  2015 output/staging/lib
lrwxrwxrwx 1     3 Jan 20 13:47 output/staging/lib32 -> lib
lrwxrwxrwx 1     3 Jan 20 13:47 output/staging/lib32-fp -> lib
drwxr-xr-x 2  4096 Jan 20 13:47 output/staging/usr/lib
lrwxrwxrwx 1     3 Jan 20 13:47 output/staging/usr/lib32 -> lib
drwxr-xr-x 4  4096 May 26  2015 output/staging/usr/lib32-fp
drwxr-xr-x 4  4096 May 26  2015 output/staging/usr/lib64-fp
drwxr-xr-x 4  4096 May 26  2015 output/staging/usr/libexec
drwxr-xr-x 3  4096 May 26  2015 output/staging/usr/libexec32
drwxr-xr-x 3  4096 May 26  2015 output/staging/usr/libexec32-fp
drwxr-xr-x 3  4096 May 26  2015 output/staging/usr/libexec64-fp
drwxr-xr-x 2  4096 Jan 20 13:48 output/target/lib
lrwxrwxrwx 1     3 Jan 20 13:47 output/target/lib32 -> lib
lrwxrwxrwx 1     3 Jan 20 13:47 output/target/lib32-fp -> lib
drwxr-xr-x 2  4096 Jan 20 13:48 output/target/usr/lib
lrwxrwxrwx 1     3 Jan 20 13:47 output/target/usr/lib32 -> lib
lrwxrwxrwx 1     3 Jan 20 13:47 output/target/usr/lib32-fp -> lib

Notice how usr/lib32-fp is not a symlink but a directory, and the presence
of an unnecessary directory usr/lib64-fp.

This patch improves the rsync exclusion rules by excluding any lib*
directory on the first rsync. As this would also exclude any
libexec/libexec32/... directory, explicitly include them first (first match
takes precedence). This (as is already the case today) results in more
usr/libexec* directories than needed, but it is not touched by this patch.

With the fix applied, the situation becomes:

drwxr-xr-x 2 4096 May 26  2015 output/staging/lib
lrwxrwxrwx 1    3 Jan 20 14:27 output/staging/lib32 -> lib
lrwxrwxrwx 1    3 Jan 20 14:27 output/staging/lib32-fp -> lib
drwxr-xr-x 4 4096 May 26  2015 output/staging/usr/lib
lrwxrwxrwx 1    3 Jan 20 14:27 output/staging/usr/lib32 -> lib
lrwxrwxrwx 1    3 Jan 20 14:27 output/staging/usr/lib32-fp -> lib
drwxr-xr-x 4 4096 May 26  2015 output/staging/usr/libexec
drwxr-xr-x 3 4096 May 26  2015 output/staging/usr/libexec32
drwxr-xr-x 3 4096 May 26  2015 output/staging/usr/libexec32-fp
drwxr-xr-x 3 4096 May 26  2015 output/staging/usr/libexec64-fp
drwxr-xr-x 2 4096 Jan 20 14:27 output/target/lib
lrwxrwxrwx 1    3 Jan 20 14:27 output/target/lib32 -> lib
lrwxrwxrwx 1    3 Jan 20 14:27 output/target/lib32-fp -> lib
drwxr-xr-x 2 4096 Jan 20 14:27 output/target/usr/lib
lrwxrwxrwx 1    3 Jan 20 14:27 output/target/usr/lib32 -> lib
lrwxrwxrwx 1    3 Jan 20 14:27 output/target/usr/lib32-fp -> lib

For cases where ARCH_LIB_DIR is one of lib, lib32 or lib64 this fix
makes no difference, and likewise for internal toolchains.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-01 14:20:05 +01:00
Thomas De Schampheleire
beddd71c57 toolchain-external: don't exclude too much lib in sysroot rsync
The copy_toolchain_sysroot helper in toolchain/helpers.mk performs an
rsync of various directories from the extracted external toolchain to the
corresponding directory in staging.

The relevant (simplified) snippet is:
    for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
            rsync -au --chmod=u=rwX,go=rX --exclude 'usr/lib/locale' \
                    --exclude lib --exclude lib32 --exclude lib64 \
                    $${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \
    done ; \

The exclusion logic of lib/lib32/lib64 has been added by commit
5628776c4a with the purpose of only copying
the relevant usr/lib* directory from the toolchain to staging, instead of
all. For example, if ARCH_LIB_DIR is 'lib64', then only usr/lib64 would be
copied and usr/lib and usr/lib32 are ignored. It works by ignoring any
lib/lib32/lib64 subdirectory on the rsync of 'usr' and then separately
copying usr/{lib,lib32,lib64} as appropriate. (The exclusion rules only have
impact on the files beneath the main source directory.)

However, on the rsync of 'usr', ANY of the following directories AND files
would be excluded:
    lib/
    lib
    lib32/
    foobar/something/lib/
    something-else/lib64/

while it is only the intention to skip directories directly under usr.

Therefore, add a leading (to restrict the scope to first-level) and trailing
(to restrict to directories) slash to the exclude pattern. From 'man rsync':

    - if the pattern starts with a / then it is anchored to [..] the root of
      the transfer.
    - if the pattern ends with a / then it will only match a directory, not
      a regular file, symlink, or device.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-01 14:19:34 +01:00
Thomas Petazzoni
07bb65c657 package, toolchain: remove BR2_TOOLCHAIN_HAS_GCC_BUG_* options
Quite some time ago, we added the options
BR2_TOOLCHAIN_HAS_GCC_BUG_58595 and BR2_TOOLCHAIN_HAS_GCC_BUG_58854 to
indicate if the toolchain was affected by those gcc bugs, which were
causing build failure with a number of packages.

With the recent change in the external toolchain logic to provide only
the latest version of each toolchain "family", all the toolchains
which were affected by those issues disappeared from Buildroot. Those
options are no longer being selected anywhere, and being blind
options, it means their value is always going to be "disabled".

Conquently, this commit removes those options completely, and updates
all the packages where they were used.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-30 11:02:30 +01:00
Vicente Olivert Riera
e424c13460 toolchain/external: add MIPS Codescape IMG GNU Linux toolchain
[Thomas:
  - rebase on top of master
  - remove version number of the Config.in option name.]

Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-01-20 10:28:05 +01:00
Vicente Olivert Riera
c65c728f54 toolchain/external: add MIPS Codescape MTI GNU Linux toolchain
[Thomas:
 - rebase on top of master
 - remove version number of the Config.in option name.]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-01-20 10:28:05 +01:00
Vicente Olivert Riera
9a1e9efe26 toolchain: allow side by side sysroot directories
Currently our toolchain infrastructure assumes that every toolchain has
nested sysroot directories. However that's not true for all of them. The
Codescape toolchains from Imagination Technologies use a side by side
sysroot structure, for instance.

This patch allows our toolchain infrastructure to detect what kind of
sysroot structure we have (nested or side by side) and performs the
appropriate actions.

[Thomas: update the comment above the function, to explain what's
going on with nested sysroots and side-by-side sysroots.]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-01-19 23:06:58 +01:00
Gustavo Zacarias
df2ad61b5e toolchain: add 4.4.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-11 17:32:41 +01:00
Romain Naour
e9f2935232 toolchain-external: CodeSourcery PowerPC: Revert the removal of CS PowerPC 2011.03
As reported by Yann E. MORIN [1], the latest CS PowerPC toolchain (2012.03)
requires a PPC CPU with SPE, which is basically two variants, 8540 (e500v1) and
8548 (e500v2) in Buildroot. All other PPC CPU can't use that toolchain.

Keep CS PowerPC 2011.03 as latest available version and add a second Kconfig
symbol for the CS PowerPC 2012.03 since it's verry specific to one CPU type
(e500v2).

Previously it was possible to select the CS 2012.03 with a powerpc 8540 (e500v1)
CPU but the sysroot provided by the toolchain only support the 8548 (e500v2)
variant. Allow to select CS 2012.03 only with BR2_powerpc_8548.

Also re-add the previous CS toolchain handling for pixman and liquid-dsp.

[1] http://lists.busybox.net/pipermail/buildroot/2015-December/148308.html

Reported-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-30 22:25:50 +01:00
Thomas Petazzoni
69e0d0e282 toolchain-external: select netbsd-queue for musl toolchains
Following the introduction of the check that target packages must have
their Config.in option enabled, we started to see failures related to
netbsd-queue. Yann fixed the internal toolchain case in commit
e84fd04e88. This commit fixes the
similar issue, but for the external toolchain case.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-30 10:03:27 +01:00
Yann E. MORIN
863036378b package/c-libraries: need linux-headers
Now that we check that a target package in the _DEPENDENCIES of another
package has to be enabled in config, all target packages must have a
kconfig symbol.

Add a Kconfig symbol for linux-headers, and select it from the packages
that depends on it (C libraries).

Also remove the now-misleading comments "for legal-info" from the C
libraries.

Fixes:
    http://autobuild.buildroot.org/results/2a9/2a9e5d27b34357819b44f573a834da1ba5079030/
    ... and numerous similar failures ...

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>
2015-12-30 09:54:33 +01:00
Yann E. MORIN
08ce10927c toolchain/external: Arago armv7 toolchain really requires a VFPv3
The Arago armv7 toolchain really requires a VFPv3 unit, so only expose
it to the user when the CPU actually has such a VFP unit

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>
2015-12-27 12:17:55 +01:00
Thomas Petazzoni
b2ec7830b6 toolchain-external: add support for musl toolchain on ARM EABIhf
Since a few releases, the pre-built musl external toolchain has added
an ARM EABIhf variant, built for ARMv5T. This commit allows this
additional external toolchain to be used.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-20 22:59:03 +01:00
Romain Naour
1820624508 toolchain-external: Ti Arago ARM: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Just rename Kconfig symbols

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-20 13:47:43 +01:00
Romain Naour
d02fa92e85 toolchain-external: Synopsys ARC: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Rename the Kconfig symbol even if this toolchain is marked as broken.

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-20 13:47:38 +01:00
Romain Naour
063593b772 toolchain-external: ADI Blackfin: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Remove old ADI toolchain handling in glog, openpgm and zeromq.

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-20 13:47:31 +01:00
Romain Naour
f4da09eafd toolchain-external: CodeSourcery x86: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-20 13:47:16 +01:00
Romain Naour
3e1ae89a99 toolchain-external: CodeSourcery SH: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-20 13:47:09 +01:00
Romain Naour
fa4214e21b toolchain-external: CodeSourcery PowerPC: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Remove old CS toolchain handling in pixman and liquid-dsp.

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-20 13:46:57 +01:00
Romain Naour
eb713cfcfb toolchain-external: CodeSourcery ARM: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-20 13:46:25 +01:00
Romain Naour
6278da1c2d toolchain-external: bump CodeSourcery MIPS to 2015.11
Use a stronger hash.

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-18 23:02:01 +01:00
Romain Naour
d9306ad168 toolchain-external: CodeSourcery MIPS: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-18 23:00:55 +01:00
Romain Naour
e7e5a7606b toolchain-external: bump CodeSourcery NIOSII to 2015.11
Some package black list CS NIOSII toolchains, mainly due to _gp link
issue. A follow up patch can remove the restriction case by case.

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-18 22:58:57 +01:00
Romain Naour
c785b1b2c4 toolchain-external: CodeSourcery NIOSII: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-18 22:57:16 +01:00
Romain Naour
09f1a3b9eb toolchain-external: bump CodeSourcery AMD64 to 2015.11
Use a stronger hash.

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-18 22:50:45 +01:00
Romain Naour
23ba818b63 toolchain-external: CodeSourcery AMD64: support only one version
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"

[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-18 22:50:30 +01:00
Sergio Prado
fa6473729c musl: add a sys/queue.h implementation
Musl does not provide a 'sys/queue.h' implementation, and this has been
a problem for packages that depend on it.

So lets create a package called netbsd-queue that will install a
'sys/queue.h' in the staging directory when enabled, based on the
NetBSD implementation.

Musl toolchain and external toolchain packages will depend on this
package, so that 'sys/queue.h' will be always installed when compiling
with a musl based toolchain.

Tested on ARM and x86 in the following cases:
  - Buildroot musl toolchain.
  - External musl toolchain without 'sys/queue.h'.
  - External musl toolchain with 'sys/queue.h'.

Fixes:
http://autobuild.buildroot.net/results/24bad2d06ab40024dacf136bee722072d587f84e

And possibly many others.

Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-17 22:02:27 +01:00
Trent Piepho
d7a92aa2fb toolchain/external: fix gdbserver install with Linaro 2015.08
In the latest Linaro toolchain, the gdbserver has moved (surprise!)
and is now located side-by-side with the toolchain executables.

This commit adds this path as a new location where to search for a
gdbserver, and while at it wraps the line that has become too long in
the process.

[Thomas: rework commit log according to Yann's suggestion.]

Signed-off-by: Trent Piepho <tpiepho@kymetacorp.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-05 23:21:38 +01:00
Arnout Vandecappelle
b731dc7bfb toolchain-external: make extraction idempotent
Commit 23ffa7ec first extracts to the toolchain-external build
directory and then moves everything to $(HOST_DIR)/opt/ext-toolchain.
However, this is not idempotent, because moving directories over
existing ones doesn't always work, particularly if the target is on
another device.

Simply remove the destination contents before moving.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-04 08:31:09 +01:00