Commit Graph

2147 Commits

Author SHA1 Message Date
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
Yann E. MORIN
d0185582d0 toolchain/external: use generic extract commands (blackfin case)
The backfin toolchains come in two archives.

We extract the first (main) archive using the generic extract commands,
while the second is extracted as a post-extract hook.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-03 22:32:03 +01:00
Yann E. MORIN
23ffa7ecf7 toolchain/external: use generic extract commands (!blackfin case)
Now that packages can provide a list of files to be excluded when
extracting their archive, downloaded external toolchains are no longer
special in this respect.

Still, those toolchains are currently extracted directly into their
final location, $(HOST_DIR)/opt/ext-toolchain/ which means we still
need a custom extract command.

Except, we don't really need it: we can just move the toolchain, after
it's been extracted by the generic extract command, with a post-extract
hook.

This means that:

  - we now extract the toolchain with the generic extract command,

  - the toolchain is thus extracted into $(@D) ,

  - fixup commands are run against $(@D), as a post-extract hook,
    instead of against $(HOST_DIR)/opt/ext-toolchain ,

  - once this is done, we move $(@D)/* into the final location with a
    new post-extract hook.

Note: the blackfin case is special, and will be handled in a follow-up
patch.

[Thomas: register the TOOLCHAIN_EXTERNAL_FIXUP_CMDS only for the Arago
case, add some additional comments in the code about why we're moving
the toolchain around.]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-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-11-03 22:30:08 +01:00
Yann E. MORIN
dbdc241d6a toolchain-external/blackfin: drop --hard-dereference
Currently, for the blackfin external toolchains, we tell tar to
extract files with the --hard-dereference. However, --hard-dereference
is only meaningful when creating an archive, not when extracting
it. Therefore, let's drop this option.

[Thomas: rework commit title and commit log, after some suggestions
from Arnout.]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-03 22:21:16 +01:00
Yann E. MORIN
24bfce0ebc toolchain/external: bump Linaro AArch64 to 2015.08
That toolchain is built for an x86_64 host, so we make it available only
for x86_64, and we keep the old 2014.09 toolchain for x86 hosts.

To avoid dealing with legacy symbols and introduce versioned options,
we reuse the same symbol for both toolchains. Thanks to the different
depednencies (on the host), we can give them different prompts and
different help texts.

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>
2015-11-03 22:02:58 +01:00
Yann E. MORIN
997ef60d90 toolchain/external: bump Linaro ARMEB to 2015.08
That toolchain is built for an x86_64 host, so we make it available only
for x86_64, and we keep the old 2014.09 toolchain for x86 hosts.

To avoid dealing with legacy symbols and introduce versioned options,
we reuse the same symbol for both toolchains. Thanks to the different
depednencies (on the host), we can give them different prompts and
different help texts.

[Thomas: tweak Config.in help text to actually match this toolchain
instead of being a wrong copy/paste from the old Linaro toolchain for
ARMeb.]

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>
2015-11-03 22:02:11 +01:00
Yann E. MORIN
9b3b98bf5a toolchain/external: bump Linaro ARM to 2015.08
That toolchain is built for an x86_64 host, so we make it available only
for x86_64, and we keep the old 2014.09 toolchain for x86 hosts.

To avoid dealing with legacy symbols and introduce versioned options,
we reuse the same symbol for both toolchains. Thanks to the different
depednencies (on the host), we can give them different prompts and
different help texts.

[Thomas: s/eglibc/glibc/ as noticed by Baruch.]

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>
2015-11-03 21:52:44 +01:00
Vicente Olivert Riera
aef2df82e1 toolchain: add 4.3.x choice for headers
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: "James Knight" <james.knight@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-02 20:56:22 +01:00
Yann E. MORIN
32e2636c51 toolchain/wrapper: fix potential bug in foreach loop
In Makefile, the comma ',' is used to separate the arguments passed to
functions, so we should not be allowed to use straight commas in strings
we want to expand.

For the toolchain wrapper, we need to transform a list:
    -mfoo -mbar -mbuz

into something acceptable for a C array assignment:
    "-mfoo", "-mbar", "-mbuz",

So, we use a $(foreach ...) loop for that. However, we do have a
straight comma in there.

It does not cause any issue in practice, since $(foreach) is a make
builtin function that accepts three and only three parameters.

However, this is not sane.

Change the straight comma to the usual $(comma) expansion, like we would
do for a call to any other function.

At the same time, make the code a bit easier to read, by first creating
the transformed list, and then creating the define.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-25 23:01:48 +01:00
Ray Kinsella
968f5d5e59 arch/x86: add support for Intel X1000
The Intel X1000 is the Pentium class microprocessor that ships with
Galileo Gen 1/2. This patch adds changes to arch and toolchain-wrapper
to omit the lock prefix for the X1000.

[Thomas: tweak commit log and Config.in help text.]

Signed-off-by: Ray Kinsella <ray.kinsella@intel.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-20 10:04:52 +02:00
Thomas Petazzoni
e811f51549 toolchain: like glibc, musl always provides SSP support
Make sure BR2_TOOLCHAIN_USES_MUSL selects BR2_TOOLCHAIN_HAS_SSP since
musl always provides SSP support (like glibc).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-18 15:35:42 +02:00
Vicente Olivert Riera
99f8084c74 toolchain-external/CodeSourcery MIPS: available only for R2
Currently the CodeSourcery toolchains for MIPS can be selected to build
mips32 (revision level 1) targets, but the resulting binaries are built
for mips32r2 instead. This is because these toolchains don't have
library support other than mips32r2, so there is no point to allow the
selection of a mips32 variant with a CodeSourcery MIPS toolchain, since
everything will be built for mips32r2 instead.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-17 16:21:46 +02:00
Arnout Vandecappelle
5ce73dca52 toolchain-external: bypass buildroot wrapper
The buildroot internal toolchain now adds a wrapper. When we use a
buildroot toolchain as an external toolchain, we want to bypass this
wrapper and call the compiler directly, for two reasons:

1. The options added by the wrapper are not necessarily appropriate
   when it is reused as an external toolchain. For instance, ccache
   may have been enabled while building the toolchain but not when
   using it as an external toolchain.

2. Currently, the wrapper expects to reside in .../usr/bin, but when
   used as an external toolchain it will be in .../ext-toolchain/bin.
   Therefore, the wrapper can't find the real binary and sysroot
   anymore.

To bypass the wrapper, we check for the existence of *.br_real files in
the external toolchain directory. If any such file exists, the wrapper
will add the .br_real suffix for all the wrapped files. Note that the
wrapper doesn't check if the *.br_real exists for each individual
wrapped file, it just assumes that all wrapped files have a
corresponding .br_real. This is currently true but that may change in
the future of course.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-17 10:50:35 +02:00
Waldemar Brodkorb
7340143a5c toolchain: add mips64 for uClibc-ng
Filter out all other uClibc versions, as they containing
serious bugs for mips64.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-13 00:01:25 +02:00
Vicente Olivert Riera
99122d6780 arch: add support for mips32r6 and mips64r6 variants
- Add support for mips32r6 and mips64r6 target architecture variants
- Disable unsupported gcc versions
- Disable unsupported binutils versions
- Disable unsupported external toolchains
- Disable unsuported C libraries
- Add a hook in order to make glibc compile for MIPS R6.

[Thomas: slightly tweak the glibc hack explanation, to make it
hopefully clearer.]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-12 21:33:56 +02:00
Waldemar Brodkorb
4a92f6754a toolchain: add sparc64 architecture support
Introduce sparc64 architecture to buildroot.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-10 12:51:45 +02:00
Peter Korsgaard
ccdb179d24 toolchain-wrapper.c: unbreak BR_CROSS_PATH_ABS handling
Fixes #8386

We should check if BR_CROSS_PATH_ABS is defined, not if it evalutates to
true for the pre processor.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-05 08:25:17 +02:00
Yann E. MORIN
87785ec159 toolchain/external: commonalise comments about Linaro toolchains
Those two comments:
  - are exactly the same
  - have the same dependencies (except for arm/armeb)

So, make it a common comment. It will be useful to have that comment
when we introduce new Linaro toolchain versions.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-04 18:33:57 +01:00
Arnout Vandecappelle
1e97b27873 ccache: support changing the output directory
When building in a different output directory than the original build,
there will currently be a lot of ccache misses because in many cases
there is some -I/... absolute path in the compilation. Ccache has an
option CCACHE_BASEDIR to substitute absolute paths with relative paths,
so they wil be the same in the hash (and in the output).

Since there are some disadvantages to this path rewriting, it is made
optional as BR2_CCACHE_USE_BASEDIR. It defaults to y because the
usefulness of ccache is severely reduced without this option.

In addition to CCACHE_BASEDIR, we also substitute away the occurences
of $(HOST_DIR) in the calculation of the compiler hash. This is done
regardless of the setting of BR2_CCACHE_USE_BASEDIR because it's
quite harmless.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 18:22:21 +02:00
Arnout Vandecappelle
f4682cf933 ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain
Our current ccache disables hashing of the compiler executable itself,
because using the default 'mtime' doesn't work in buildroot: we always
rebuild the compiler, so the mtime is always different, so the cache
always misses.

However, in the current situation, if a user changes the compiler
configuration (which would result in the compiler generating different
object files than before) and does 'make clean all', ccache may in fact
reuse object files from the previous run. This rarely gives problems,
because
(1) the cache expires quite quickly (it's only 1GB by default),
(2) radically changing compiler options will cause cache misses because
    different header files are used,
(3) many compiler changes (e.g. changing -mtune) have little practical
    effect because the resulting code is usually still compatible,
(4) we currently don't use CCACHE_BASEDIR, and almost all object files
    will contain an absolute path (e.g. in debug info), so when
    building in a different directory, most of it will miss,
(5) we do mostly build test, and many of the potential problems only
    appear at runtime.
Still, when ccache _does_ use the wrong cached object files, the
effects are really weird and hard to debug. Also, we want reproducible
builds and obviously the above makes builds non-reproducible. So we
have a FAQ entry that warns against using ccache and tells the user to
clear the cache in case of problems.

Now that ccache is called from the toolchain wrapper, it is in fact
possible to at least use the 'mtime' compiler hash for the external
toolchain and for the host-gcc. Indeed, in this case, the compiler
executable comes from a tarball so the mtime will be a good reference
for its state. Therefore, the patch (sed script) that changes the
default from 'mtime' to 'none' is removed.

For the internal toolchain, we can do better by providing a hash of
the relevant toolchain options. We are only interested in things that
affect the compiler itself, because ccache also processes the header
files and it doesn't look at libraries because it doesn't cache the
link step, just compilation. Everything that affects the compiler
itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of
course, also the compiler source itself is relevant, so the source
tarball and all the patches are included in the hash. For this purpose,
a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced.

The following procedure tests the ccache behaviour:

 Use this defconfig:
BR2_arm=y
BR2_CCACHE=y

 make
 readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os
-> Tag_CPU_name: "ARM926EJ-S"

 Now make menuconfig, change variant into BR2_cortex_a9

 make clean; make
 readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os
-> Tag_CPU_name: "ARM926EJ-S"
 should be "Cortex-A9"

After this commit, it is "Cortex-A9".

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Danomi Manchego <danomimanchego123@gmail.com>
Cc: Károly Kasza <kaszak@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 18:22:21 +02:00
Arnout Vandecappelle
792f1278e3 toolchain-wrapper: support change of BR2_CCACHE
By moving the ccache call to the toolchain wrapper, the following
scenario no longer works:

make foo-dirclean all BR2_CCACHE=

That's a sometimes useful call to check if some failure is perhaps
caused by ccache.

We can enable this scenario again by exporting BR_NO_CCACHE when
BR2_CCACHE is not set, and by handling this in the toolchain wrapper.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 18:22:20 +02:00
Arnout Vandecappelle
d82f69cf10 infra: move ccache handling to the toolchain wrapper
Since we always have a toolchain wrapper now, we can move the ccache
call to the toolchain wrapper.

The hostcc ccache handling obviously stays.

The global addition of ccache to TARGET_CC/CXX is removed, but many
individual packages and infras still add it. This means we have a
chain like this: ccache -> toolchain-wrapper -> ccache -> gcc
However, this is fairly harmless: for cache misses, the inner ccache
just adds overhead and for cache hits, the inner ccache is never
called. Later patches will remove these redundant ccache calls.

As a side effect, perl now supports ccache as well.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Danomi Manchego <danomimanchego123@gmail.com>
Cc: Károly Kasza <kaszak@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 18:22:20 +02:00
Arnout Vandecappelle
919c06c282 gcc: use toolchain wrapper
We have a toolchain wrapper for external toolchain, but it is also
beneficial for internal toolchains, for the following reasons:

1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the
   compiler even if a package's build system doesn't honor CFLAGS.
2. It allows us to do the unsafe path check (i.e. -I/usr/include)
   without patching gcc.
3. It makes it simpler to implement building each package with a
   separate staging directory (per-package staging).
4. It makes it simpler to implement a compiler hash check for ccache.

The wrapper is reused from the external toolchain. A third CROSS_PATH_
option is added to the wrapper: in this case, the real executable is in
the same directory, with the extension .real.

The creation of the simple symlinks is merged with the creation of the
wrapper symlinks, otherwise part of the -gcc-ar handling logic would
have to be repeated.

The complex case-condition could be refactored with the one for the
external toolchain, but then it becomes even more complex because
they each have special corner cases. For example, the internal
toolchain has to handle *.real to avoid creating an extra indirection
after host-gcc-{final,initial}-rebuild.

Instead of creating the .real files, it would also have been possible
to install the internal toolchain in $(HOST_DIR)/opt, similar to what
we do for the external toolchain. However, then we would also have to
copy things to the sysroot and do more of the magic that the external
toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much
simpler.

Note that gcc-initial has to be wrapped as well, because it is used for
building libc and we want to apply the same magic when building libc.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 18:22:20 +02:00
Arnout Vandecappelle
f6ae24379b toolchain-external: move wrapper to toolchain directory
The toolchain wrapper will be reused for the internal toolchain, so it
belongs in the toolchain directory. Also, the ext- prefix is removed
from it. The build commands are moved to a new toolchain-wrapper.mk.

The wrapper arguments that are also relevant for the internal toolchain
wrapper are moved to toolchain-wrapper.mk, the rest stays in
toolchain-external.mk.

While we're at it, move the building of the toolchain wrapper to the
build step of toolchain-external. There is no specific reason to do
this, other than that it fits better semantically. Also remove the
MESSAGE call, otherwise we'd see:
>>> toolchain-external undefined Building
>>> toolchain-external undefined Building toolchain wrapper
/usr/bin/gcc ...
Having an extra "Building toolchain wrapper' message is pointless.

The useless condition on $(BR2_TARGET_OPTIMIZATION) is removed. It was
always true because it wasn't qstrip'ped first, so clearly it works
without that condition as well.

Also rewrapped some comments and removed the 'external' reference.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 18:22:19 +02:00
Luca Ceresoli
eb5e5b49d6 toolchain-external: define actual sources for arago toolchains
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-04 17:03:38 +01:00
Luca Ceresoli
b8d7b6670f toolchain-external: mass-define actual source tarball for known patterns
For some external toolchain vendors the actual source code URL can be simply
derived from the binary file URL.

Here we obtain TOOLCHAIN_EXTERNAL_ACTUAL_SOURCE_TARBALL for all Mentor and
Linaro toolchains with a few $(subst) calls.

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-04 17:03:30 +01:00