Commit Graph

2282 Commits

Author SHA1 Message Date
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
Maxime Hadjinlian
24dc187061 toolchain-external: Remove BLACKFIN_UCLINUX_2012R2
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-04 16:11:24 +01:00
Luca Ceresoli
e4624fce8a toolchain-external: strip trailing slash from autogenerated FOO_SITE
Trailing slashes are going to be declared illegal from FOO_SITE
variables.

But Buildroot internally generates such a variable when using a custom
external toolchain (i.e. BR2_TOOLCHAIN_EXTERNAL_CUSTOM). This is
because TOOLCHAIN_EXTERNAL_SITE is set to
$(dir $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_URL))), and $(dir)
leaves a trailing slash.

Fix it using patsubst, just like linux and the bootloaders do.

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-04 15:46:11 +01:00
Maxime Hadjinlian
8f59da8552 toolchain: Fix glibc breakage
Introduced by previous patch 0f75b2635e,
this printf would break the build of glibc, because there is no format
to printf:

    printf: usage: printf [-v var] format [arguments]

Signed-off-by Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reported-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 13:59:46 +02:00
Maxime Hadjinlian
0f75b2635e package: Replace 'echo -n' by 'printf'
'echo -n' is not a POSIX construct (no flag support), we shoud use
'printf', especially in init script.

This patch was generated by the following command line:
git grep -l 'echo -n' -- `git ls-files | grep -v 'patch'` | xargs sed -i 's/echo -n/printf/'

Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04 00:56:41 +02:00
vicencb@gmail.com
066fd9017f toolchain-external: fix musl-based builds on ARMhf platforms
When ARCH is arm and the hard-floating-point option is on executables
expect to find the dynamic linker at /lib/ld-musl-armhf.so.1 and not
/lib/ld-musl-arm.so.1.

This patch adjusts the logic that creates the symbolic link from the
dynamic linker path to the musl C library (since musl has everything
built into a single file).

[Thomas: tweak the commit log.]

Signed-off-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-28 22:41:22 +02:00
Vicente Olivert Riera
cb68e9fccb toolchain-external/CodeSourcery MIPS 2015.05: fix lib-names headers
The CodeSourcery MIPS 2015.05 toolchain has some missing headers we need
to create manually in order to avoid compilation errors. A bug has been
already reported and fixed upstream, and the fix will be included in the
next release.

Fixes:
  http://autobuild.buildroot.net/results/bea/bea76392dec5c8e1bcea8be990ad109c6d27e947/
  http://autobuild.buildroot.net/results/64f/64f2b6b6e60d5c2d9537ad6891211cda6baaf6d5/
  ...and many more.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-09-13 22:22:36 +02:00
Arnout Vandecappelle
797318b483 toolchain-external: clarify the comment about *-gcc-ar... LTO wrappers
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-13 12:38:25 +02:00
Arnout Vandecappelle
cdbaba0a2e toolchain-external: trivial clean up of messages
Before this commit, the output of the toolchain-external build steps
looked like this (abbreviated for clarity):

>>> toolchain-external undefined Building
>>> toolchain-external undefined Installing to staging directory
>>> toolchain-external undefined Copying external toolchain sysroot to staging...
>>> toolchain-external undefined Building ext-toolchain wrapper
mkdir -p output/host/usr/bin; cd output/host/usr/bin; for i in ...
/usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='...
if test -f output/host/usr/bin/i686-pc-linux-gnu-gdb ; then mkdir -p ...
>>> toolchain-external undefined Fixing libtool files
>>> toolchain-external undefined Installing to target
>>> toolchain-external undefined Copying external toolchain libraries to target...
if test -e output/target/lib/ld-uClibc.so.1; then ln -sf ld-uClibc.so.1 output/target/lib/ld-uClibc.so.0 ; fi
if test -e output/target/lib/ld64-uClibc.so.1; then ln -sf ld64-uClibc.so.1 output/target/lib/ld64-uClibc.so.0 ; fi

All the long lines with conditions and loops in them are not usefull,
so put $(Q) in front of them. The line with mkdir can better be split
on a separate line so the cd stands out more. There are two redundant
semicolons that can be removed. The installation of gdbinit could
use an extra message so the user can see what is going on.

After this commit, the toolchain-external build steps look like this:
>>> toolchain-external undefined Building
>>> toolchain-external undefined Installing to staging directory
>>> toolchain-external undefined Copying external toolchain sysroot to staging...
>>> toolchain-external undefined Building ext-toolchain wrapper
/usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='...
>>> toolchain-external undefined Installing gdbinit
>>> toolchain-external undefined Fixing libtool files
>>> toolchain-external undefined Installing to target
>>> toolchain-external undefined Copying external toolchain libraries to target...

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-13 12:37:48 +02:00
Thomas Petazzoni
c8a4c08571 toolchain-external: finish removal of SH2A toolchains
Commit c68c365d29 ("toolchain-external:
remove CS sh2 toolchains") removed the definitions of the
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_SH2A_201103 and
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_SH2A_201009, but did not actually
remove the code that was using those options.

So this commit removes the parts of the code that are currently dead
due to this: the definition of the prefix of those toolchains, the
hashes, and the URLs.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-09-08 00:10:27 +02:00
Peter Korsgaard
8dc6829337 toolchain: add 4.2.x choice for headers
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-09-01 10:05:20 +02:00
Yann E. MORIN
23fde76859 toolchain/external: ensure gcc version is known
Currently, when a preconfigured prebuilt toolchain forgets to specify
its gcc version, the error message is a bit misleading, like:

    Incorrect selection of gcc version: expected .x, got 4.9.2

Add a an explicit check for the gcc version being set, that reports a
better error message.

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-08-18 11:47:23 +02:00
Yann E. MORIN
4a5f878946 toolchain/external: better check for gcc-5
gcc will always report a three-digit version sting, like 4.9.3 or 5.1.0.

For gcc before 5, we want to check the first two digits, while starting
with gcc 5, we are only concerned about the first digit.

So, change our matching code to test for the leading part of the version
string, up to the first dot after as-many version digit we're interested
in.

Note: we're adding the dot in the .mk code rather than in the Kconfig
symbol, because it seemed cleaner to do so.

Reported-by: Jörg Krause <joerg.krause@embedded.rocks>
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-08-09 16:58:55 +02:00
Thomas Petazzoni
bd760c3f51 toolchain-external: add support for gcc version dependency
This commit wires up the gcc version dependency mechanism in the
external toolchain backend. To do so, it:

 * Changes the definition of all pre-defined external toolchain
   profiles to select the appropriate BR2_TOOLCHAIN_GCC_AT_LEAST_*
   option.

 * For custom external toolchains, provides a visible Config.in
   "choice" to select the gcc version used in the external toolchain.

 * Adds a new check_gcc_version function, that verifies that the real
   gcc version found in the external toolchain matches the one
   declared in the Buildroot configuration.

[Thomas: use better sed expression proposed by Yann E. Morin, which
works with more cases.]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-08-05 12:11:20 +02:00
Thomas Petazzoni
8ba2a76892 toolchain: add common gcc version hidden config options
This commit adds a number of hidden Config.in options, that will be
used to handle dependencies on the gcc version. We mimic the model
that was used for the kernel headers dependency mechanism.

These hidden options will be selected by the internal and external
toolchain backend logic respectively, in follow-up commits.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2015-08-05 10:40:19 +02:00
Thomas De Schampheleire
b62cb78d6f toolchain-external wrapper: don't pass march/mcpu if mtune is on cmdline
Before commit 5715d2dcf4, the external
toolchain wrapper would not pass its own march/mcpu/mtune flags to the real
compiler if at least one of them was passed on the wrapper command-line.

The mentioned commit intended to remove the passing of an mtune parameter
coming from Buildroot, which was always empty after some other refactoring,
but the changes have the side-effect that march/mcpu is now also passed when
mtune is already given on the command-line. In that case, only mtune should
be passed to the real compiler.

Restore part of the original toolchain wrapper code to check the presence of
mtune on the command-line.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-26 15:20:10 +02:00
Thomas De Schampheleire
ee4e4a96d7 trivial: fix typo optimazation
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-17 19:39:19 +02:00
Baruch Siach
6ec1582028 toolchain-external: fix uClibc-ng 64bit dynamic loader link
Commit 34f95bf9db (toolchain-external: fix support of uClibc-ng toolchains,
2015-07-13) added the missing ld-uClibc.so.1 dynamic linker symlink that
binaries expect when linked with uClibc-ng. However on 64bit targets the
linker is called ld64-uClibc.so.1. Handle that case as well.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-16 23:12:06 +02:00
Thomas Petazzoni
34f95bf9db toolchain-external: fix support of uClibc-ng toolchains
The uClibc-ng dynamic loader is called ld-uClibc.so.1, but gcc is not
patched specifically for uClibc-ng, so it continues to generate
binaries that expect the dynamic loader to be named ld-uClibc.so.0,
like with the original uClibc.

Therefore, when a uClibc-ng toolchain is used as an external
toolchain, we need to create an additional symbolic link to make
uClibc-ng systems work properly.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-14 10:07:55 +02:00
Bai Yingjie
bacf215719 toolchain-external: improve lib subdirectory matching
The toolchain from the Cavium Networks Octeon SDK provides a sysroot
with library directories lib32, lib32-fp, lib64 and lib64-fp. The -fp
variants are used for processors with hardware floating point unit, such
as the Octeon III variants.

When specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, the toolchain
will use lib32-fp, but currently Buildroot does not accept that pattern.

This patch improves the matching by accepting lib(32|64)?([^/]*)? as lib
directory name.

Signed-off-by: Bai Yingjie <byj.tea@gmail.com>
[ThomasDS: update commit message]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[Thomas: add comment above the function being modified to illustrate
the various cases we try to handle.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-13 17:26:22 +02:00
Guido Martínez
40b28322b3 toolchain/helpers.mk: use --chmod on rsync
This makes sure we don't have any weird permissions on the staging dir,
which could affect the target.

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-13 17:13:15 +02:00
Bamvor Jian Zhang
827ba46556 aarch64: add big endian(aarch64_be) support
Add aarch64_be support. Note that CONFIG_CPU_BIG_ENDIAN should be
defined in kernel config when building a big endian kernel.

Signed-off-by: Zhang Jian(Bamvor) <bamvor.zhangjian@huawei.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-12 18:32:37 +02:00
Thomas Petazzoni
22ed697d11 packages: do not use TAR_STRIP_COMPONENTS, but directly --strip-components
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-12 13:51:59 +02:00
Guido Martínez
375bc18850 toolchain: allow for stupid toolchains
check_arm_abi builds a test C file to check that the toolchain is
working correctly, with the output redirected to /dev/null.

However, some toolchains (OSELAS 2014.12.0, for instance) foolishly
append ".gdb" to the output filename for an intermediate file, causing
an attempt to write to /dev/null.gdb, which obviously fails.

Fix this by adding changing the output to a temporary file, which is
later removed along with any other "suffixed" files.

Suggested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-28 14:32:40 +02:00
Thomas Petazzoni
dab385644a toolchain-buildroot: mark eglibc as deprecated
eglibc is a dead project and has not been making any release since a
while, now that glibc is back and kicking. So let's deprecated our
eglibc support.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-06-23 00:24:31 +02:00
Gustavo Zacarias
dae7d8aa5d toolchain: add 4.1.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-22 18:19:34 +02:00
Guido Martínez
29563047e0 arch: tidy up mmu config
Instead of blacklisting which architectures support MMUs (mandatorily
or optionally), introduce two Kconfig options that are selected by each
architecture in each case.

This simplifies the logic in BR2_USE_MMU.

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-09 22:49:39 +02:00
Vicente Olivert Riera
9f4ec37656 toolchain-external: add CodeSourcery MIPS 2015.05, remove 2013.11
- Add CodeSourcery MIPS 2015.05 toolchain
- Remove CodeSourcery MIPS 2013.11 toolchain
- Update the hash file

Toolchain datasheet:
  https://sourcery.mentor.com/GNUToolchain/release3068?@template=datasheet

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-06-04 22:46:34 +02:00
Yann E. MORIN
808c3fb8d2 toolchain/external: better report RPC error for custom toolchains
Currently, we instruct users to enable/disable BR2_TOOLCHAIN_HAS_NATIVE_RPC
but that is a blind option. The only option users can set/unset is
BR2_TOOLCHAIN_EXTERNAL_INET_RPC.

Use that in the error message.

Notes: the only way for this message to appear is for a custom external
toolchain, either downloaded or pre-installed, so even though we check
the validity of the toolchain with BR2_TOOLCHAIN_HAS_NATIVE_RPC, we do
report on BR2_TOOLCHAIN_EXTERNAL_INET_RPC.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-05-05 22:45:51 +02:00
Peter Korsgaard
3ed34ff119 toolchain-external: mark musl based toolchains as experimental
Like we do for the internal musl backend. We still see a large number of
build failures with musl, so warn users about it.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-05-04 16:01:37 +02:00
Waldemar Brodkorb
19d5953bf1 sh4: fix toolchain creation
The Linux kernel does force compile with -m4-nofpu, which is only
available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for
gcc configure, but enables --with-multilib-list=m4,m4-nofpu in
the default configuration for Qemu targeting r2d emulation.
This results in a toolchain, which can be used for the kernel and
for userland without creating a multilib toolchain with different
kinds of libgcc version. In the multilib case there would be
subdirectories created (!m4 and m4-nofpu). As buildroot uses a
short version of toolchain creation, a multilib enabled gcc build
fails when creating libgcc.

So the best solution is to just keep multilib disabled, but always
add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen.

Tested with sh4/sh4a toolchain build and qemu defconfig with
gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc.

Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 (ARM and SH4 uClibc toolchain builds)
2015-05-03 16:30:36 +02:00
Arnout Vandecappelle
cf3854a419 toolchain-external: remove non-existent mips-sf musl toolchains
Since 1.1.6, the mips softfloat toolchains are merged into the mips
toolchain using multilib. Our external toolchain infrastructure copies
the correct version to the target depending on the BR2_SOFT_FLOAT
option.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-05-01 22:48:30 +02:00
Arnout Vandecappelle
3a8e129209 toolchain-external: add hashes for musl toolchains
Add hashes for all musl toolchains, including the ones that we
currently don't support (arm hf, sh4, x86_64-x32).

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-05-01 22:44:04 +02:00
Thomas Petazzoni
22a59e1bc2 toolchain-external: fix rebuild/reinstall for Linaro toolchains
For Linaro toolchains, a special post install staging hook is used to
create two symlinks needed for the dynamic loader to find the
libraries. However, the way the link is created prevents a 'make
toolchain-external-reinstall' from succeeding, because the symlink
already exists and points to a directory:

ln -sf . /home/thomas/projets/outputs/training/target/lib/arm-linux-gnueabihf
ln: '/home/thomas/projets/outputs/training/target/lib/arm-linux-gnueabihf/.': cannot overwrite directory

This commit adjust the hook to pass the '-n' option so that the link
name is treated as a normal file if it is a symbolic link to a
directory.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2015-05-01 16:30:13 +02:00
Thomas Petazzoni
cd3c00fbc0 toolchain-external: mark Synopsys toolchain as broken
This uClibc toolchain does not provide an appropriate uClibc
configuration for Buildroot: missing IPv6, missing nsl stub, missing
program invocation, etc. Therefore, we mark it as broken, waiting for
a new upstream release of a new toolchain.

We keep around the toolchain-external Synopsys code anyway, since it
will most likely be identical for the new toolchain version. However,
we remove all the quirks that were introduced to start work around
issues related to this toolchain.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-05-01 11:13:54 +02:00
Yann E. MORIN
dd05cfa311 toolchain/external: ignore missing hash for custom downloaded toolchain
We will *always* be missing a hash file for custom external toolchains
that are downloaded.

So, just ignore that failure.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-25 11:51:25 +02:00
Will Wagner
2e313e1376 toolchain-external: update musl-cross toolchain to 1.1.6
The 1.1.6 version of musl-cross fixes the two issues that had been
preventing versions after 1.1.1 being used by buildroot, namely:
- sysroot is enabled again
- kernel headers are included again

Signed-off-by: Will Wagner <will_wagner@carallon.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-23 17:15:44 +02:00
Gustavo Zacarias
4bcacfd2c0 toolchain: drop BR2_INET_IPV6
It's no longer used so farewell.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-22 23:07:02 +02:00
Gustavo Zacarias
51eaa2ca15 toolchain: make IPv6 mandatory for external toolchains
Remove BR2_INET_IPV6 select for predefined external toolchains.

Remove the (non)IPv6 option prompt since it's now mandatory.

And force the toolchain check now that internal uclibc is always built
with IPv6 support and external non-IPv6 toolchains are disallowed.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-22 22:59:31 +02:00
Gustavo Zacarias
c68c365d29 toolchain-external: remove CS sh2 toolchains
Normally we'd deprecate them, but:

1) They don't support IPv6 and it's being removed so it makes no sense.
2) They're based on uClibc 0.9.30-ish which is very old and surely has
package build breakage all over it.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-22 22:59:08 +02:00
Yann E. MORIN
fb5cbf3198 toolchain: fix installing gconv libs with multi-arch toolchain
For a multi-arch toolchain, gconv modules are in a sub-directory named
after the machine gcc targets. This is the case, for example, for the
Linaro ARM 2014.09 toolchain, which has the gconv modules in (relative
to the sysroot):
    /usr/lib/arm-linux-gnueabihf/gconv

while the Sourcery CodeBench ARM 2014.05 (non-multi-arch) has them in:
    /usr/lib/gconv

So, to catter for both cases, search both paths. We want to favour the
machine-specific gconv modules over potentially existing "generic" ones,
so we first search that (if it exists) and fallback to looking in the
generic location.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-22 22:30:34 +02:00
Gustavo Zacarias
d0b812533c toolchain-external: install libatomic
It's required in some 32-bit architectures for the extended (64-bit)
atomic operations, like __sync_add_and_fetch_8.
These arches are at least: i386, mips & mipsel.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-19 14:40:05 +02:00
Gustavo Zacarias
e714ee9412 toolchain: add 4.0.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-13 22:14:42 +02:00
Yann E. MORIN
defb965893 toolchain/external: do not accept distro-class toolchains
Distro toolchains, i.ie. toolchains coing with distributions, will
almost invariably be unsuitable for use with Buildroot:
  - they are mostly non-relocatable;
  - their sysroot is tainted with a lot of extra libraries.

Especially, the toolchains coming with Ubuntu (really, all the Debian
familly of distros) are configured with --sysroot=/ which makes them
non-relocatable, and they already contain quite some libraries that
conflict (in any combination of version, API or ABI) with what Buildroot
wants to build (i.e. extra libraries, some not even present in
Buildroot...) but also their mere preence when Buildroot does not expect
them to be already built (so that a package would enable features when
it should not).

So, try to detect those toolchains and black-list them; inform the user
that the toolchain is unusable for the reasons mentioned above.

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-04-04 17:02:46 +02:00
Gustavo Zacarias
1cb087b28b toolchain-common: drop BR2_LARGEFILE
It's now unused so remove it.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01 22:53:41 +02:00
Gustavo Zacarias
152d6414ca toolchain: remove LARGEFILE selects
There's no need for toolchains or the user to declare largefile support
since it's now mandatory.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01 22:42:47 +02:00
Gustavo Zacarias
f360fec787 toolchain-common: default to Y for LARGEFILE
This will allow us to remove largefile handling in the tree without
breaking things while doing so.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01 22:42:32 +02:00
Gustavo Zacarias
7f96ef3580 toolchain/helpers: make LFS mandatory for uclibc toolchains
As discussed on the mailing list drop the non-largefile option for
toolchains.
The size delta is minimal and it just complicates package dependencies.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01 22:42:02 +02:00
Gustavo Zacarias
1c51a80a7f toolchain/helpers: add check for mandatory uClibc options
We currently only check that the Buildroot configuration matches what is
available in the toolchain.

Since we're going to remove the check for LFS and make it a mandatory
feature, we will lose the corresponding buildroot option, so we won't be
able to use check_uclibc_feature as-is.

Introduce a magic value passed as the buildroot option name to recognise
checks for mandatory uclibc options that do not have a corresponding
option in buildroot.

If the buildroot option name is empty then the check is against a
mandatory uclibc option.

If a mandatory uclibc option is missing we reject the toolchain as being
unusable by buildroot.

[Thomas: minor tweaks in comment, remove space instead of tab.]

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01 22:41:27 +02:00
Lionel Orry
ab98c9625c toolchain: enable musl for sh
The SuperH architecture is supported by the musl libc since some time
now, so let's enable it.
Tested via qemu_sh4_r2d_defconfig.

Signed-off-by: Lionel Orry <lionel.orry@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-25 20:01:55 +01:00
Gustavo Zacarias
6e404d5294 toolchain: enable musl for aarch64
musl 1.1.7 brings in experimental aarch64 support so enable it.
Tested via qemu_aarch64_virt_defconfig.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-03-19 21:49:37 +01:00
Gustavo Zacarias
aef5a87ef5 toolchain: disable internal for blackfin
The internal toolchain was a "best effort" approach - we strived to make
it build properly and all but it's mostly untested.
Since it's got issues disable it until it's properly fixed and tested
and leave the official ADI toolchain instead.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-17 17:53:13 +01:00
Alexey Brodkin
2b93fe5374 toolchain-external: add Synopsys DesignWare tools for ARC cores
With this change we add pre-built external toolachins for DesignWare ARC
cores. All currently existed flavours are supported:
 * ARC 700 and ARC HS cores
 * Little- and big-endian configurations

These pre-built tools are built with build scripts available here
(https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/tree/arc-2014.12)
and correspond to arc-2014.12 release of sources.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
2015-03-16 14:20:54 +01:00
Thomas Petazzoni
23ecfd04e6 toolchain-external: fix support for non-ADI Blackfin external toolchains
The computation of TOOLCHAIN_EXTERNAL_BIN has a special case for
Blackfin, where it's set to
$(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/$(TOOLCHAIN_EXTERNAL_PREFIX)/bin
instead of $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/bin for other
architectures.

However, this is actually only true for Analog Devices pre-built
toolchains. Other Blackfin external toolchains (such as ones built by
Buildroot) do not have this special organization.

Therefore, in order to make those non-ADI Blackfin toolchains work, we
need to change the condition from BR2_bfin to testing specifically for
the ADI toolchains.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-15 15:40:30 +01:00
Luca Ceresoli
b0b9606530 Remove trailing slash from all package site URLs
The recommended form is without the trailing slash. Buildroot will add a slash
between FOO_SITE and FOO_SOURCE as appropriate.

Reported-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-03-10 20:40:08 +01:00
Peter Kümmel
814f63ec32 toolchain: add link-time-optimization support
Add a new option BR2_GCC_ENABLE_LTO that builds gcc and binutils with
LTO support.

Individual packages still have to enable LTO explicitly by passing '-flto' to
GCC, which passes it on to the linker. This option does not add that flag
globally. Some packages detect if the compiler supports LTO and enable the flag
if it does.

To support LTO, ar and ranlib must be called with an argument which triggers the
usage of the LTO plugin. Since GCC doesn't call these tools itself, it instead
provides wrappers for ar and ranlib that pass the LTO arguments. This way
existing Makefiles don't need to be changed for LTO support. However, these
wrappers are called <tuple>-gcc-ar which matches the pattern to link to the
buildroot wrapper in the external toolchain logic. So the external toolchain
logic is updated to provide the correct symlink.

[Thomas:
  - Add a separate BR2_BINUTILS_ENABLE_LTO option to enable LTO
    support in binutils. This is a blind option, selected by
    BR2_GCC_ENABLE_LTO. It just avoids having binutils.mk poke
    directly into gcc Config.in options.
  - Remove the check on the AVR32 special gcc version, which we don't
    support anymore.
  - Adapt the help text of the LTO Config.in option to no longer
    mention "Since version 4.5", since we only support gcc >= 4.5 in
    Buildroot anyway.
  - Fix typo in toolchain-external.mk comment.]

Signed-off-by: Peter Kümmel <syntheticpp@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-07 15:01:53 +01:00
Gustavo Zacarias
d6fbd85027 toolchain-external: add CodeSourcery AMD64 2014.05
This toolchain is AMD64-only so restrict it accordingly.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-04 22:17:03 +01:00
Gustavo Zacarias
50451998f0 arch: add support for AMD steamroller
Add support for AMD steamroller optimizations, available in gcc 4.8+ as
bdver3.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-04 22:16:41 +01:00
Gustavo Zacarias
bad25aff36 toolchain/external: remove xilinx microblaze v2/14.3 toolchains
These have been deprecated since 2014.02

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-04 22:13:24 +01:00
Gustavo Zacarias
c300c8b24a toolchain/buildroot: default to glibc where possible/convenient
Default to glibc over eglibc where it's possible and/or convenient.
Since the eglibc project is basically gone and merged with glibc it
doesn't make sense to keep defaulting to it for architectures that
aren't uClibc-capable.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-04 19:42:13 +01:00
Peter Korsgaard
7403ea730d Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-03-02 23:26:20 +01:00
Baruch Siach
694dc0c8ee toolchain-external: clarify external toolchain description
External toolchain can also have been generated by Buildroot previously, as
the list that follows demonstrates. Rephrase the paragraph describing what an
external toolchain is as suggested by Thomas Petazzoni, to make it clearer.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-20 09:25:26 +01:00
Ezequiel García
ee2ccf0d64 toolchain: Enable the internal toolchain for nios2
For now we can only support glibc.

Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-19 22:04:26 +01:00
Yann E. MORIN
5272eabd61 toolchain/external: avr32 is no more
Slightly reword a comment to no longer mention avr32.

This part dealing with sysroot detection will have to be reworked, now
that we got rid of avr32: we can now require a fully sysroot-aware
toolchain, i.e. at least gcc-4.4.

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-02-14 17:43:39 +01:00
Yann E. MORIN
3d3cc4b27f toolchain/buildroot: forget about avr32
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-14 17:43:33 +01:00
Peter Korsgaard
81366edd7c toolchain: add 3.19 choice for headers
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-02-09 13:31:23 +01:00
Thomas Petazzoni
054269ac0e toolchain-external: split target installation from staging installation
Currently, all the installation work of the toolchain-external package
is done during the install-staging step. However, in order to be able
to properly collect the size added by each package to the target
filesystem, we need to make sure that toolchain-external installs its
files to $(TARGET_DIR) during the install-target step.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Jérôme Pouiller <jezz@sysmic.org>
2015-01-10 18:00:05 +01:00
Yann E. MORIN
27404dad33 toolchain: add hashes for all remaining external toolchains
Getting the hashes from upstream is not always possible:
  - Mentor's Sourcery: seems to require an account
  - TI's Arago: not able to locate the upstream.
  - Linaro: only signatures
  - Misc other toolchains.

So, all hashes were locally computed.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-01-07 22:42:25 +01:00
Thomas Petazzoni
10b97618f5 toolchain-external: add hashes for Blackfin toolchains
Those toolchains are downloaded from Sourceforge, and are therefore
affected by the Sourcefoge download issues. Therefore, this commit
adds the hashes for those toolchain tarballs.

Fixes:

  http://autobuild.buildroot.org/results/fa5/fa5e38246dddd661f1d674f3521d21297796bce3/
  (and other similar issues)

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-28 22:41:04 +01:00
Yann E. MORIN
01c34b38a4 toolchain: get rid of -pipe from optimisations
-pipe is causing some build failures in Linux kernel >= 3.17.

Also, nowadays, using -pipe does not gain as much as it used to back in
the days:

Measurements made with a 3.16.7 Linux kernel:
    make linux-depends
    time sh -c 'make linux-build >/dev/null 2>&1'

Without -pipe:
    716.32user 54.44system 3:42.12elapsed 346%CPU
    721.22user 54.47system 3:41.81elapsed 349%CPU
    722.44user 54.00system 3:42.13elapsed 349%CPU
    721.03user 53.81system 3:41.92elapsed 349%CPU
    713.21user 53.63system 3:40.51elapsed 347%CPU
    706.67user 52.42system 3:38.40elapsed 347%CPU
    714.40user 53.18system 3:40.16elapsed 348%CPU
    706.01user 53.09system 3:37.87elapsed 348%CPU
    705.98user 53.01system 3:38.03elapsed 348%CPU
    714.17user 53.55system 3:39.98elapsed 348%CPU
Average:                   3:40.29elapsed

With -pipe:
    720.13user 53.90system 3:41.98elapsed 348%CPU
    713.38user 53.69system 3:40.44elapsed 347%CPU
    711.60user 52.81system 3:39.06elapsed 348%CPU
    708.66user 53.09system 3:38.59elapsed 348%CPU
    711.76user 53.00system 3:38.48elapsed 350%CPU
    717.85user 53.97system 3:41.77elapsed 348%CPU
    716.77user 53.77system 3:40.91elapsed 348%CPU
    717.48user 53.65system 3:41.24elapsed 348%CPU
    721.44user 55.67system 3:43.45elapsed 347%CPU
    724.61user 55.63system 3:43.35elapsed 349%CPU
Average:                   3:40.93elapsed

The delta is well in the measurement noise.

Just get rid of it.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-21 22:04:59 +01:00
Thomas Petazzoni
665e13c85e Rename BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS
Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed
from "prefer static libraries when possible" to "use only static
libraries". The former semantic didn't make much sense, since the user
had absolutely no control/idea of which package would use static
libraries, and which packages would not. Therefore, for quite some
time, we have been starting to enforce that BR2_PREFER_STATIC_LIB
should really build everything with static libraries.

As a consequence, this patch renames BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS, and adjust the Config.in option accordingly.

This also helps preparing the addition of other options to select
shared, shared+static or just static.

Note that we have verified that this commit can be reproduced by
simply doing a global rename of BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 22:48:13 +01:00
Thomas Petazzoni
5aa205eba4 toolchain-external: instrument wrapper to warn about unsafe paths
The CodeSourcery toolchains have a very interesting feature: they warn
the user when an unsafe header or library path is used, i.e a path
that will lead host headers or libraries to leak into the build.

This commit adds a similar functionality into our external toolchain
wrapper, so that it can be used with all external toolchains, and can
also be tuned as needed. By default, the external toolchain wrapper
now gives warnings such as:

  arm-linux-gcc: WARNING: unsafe header/library path used in cross-compilation: '-I /usr/foo'
  arm-linux-gcc: WARNING: unsafe header/library path used in cross-compilation: '-L /usr/bleh'

but the compilation continues successfully. One can then easily grep
in his build log to search for occurences of this message.

Optionally, if BR_COMPILER_PARANOID_UNSAFE_PATH is defined in the
environment to a non empty value, the external wrapper will instead
error out and abort the compilation.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Tested-by: Romain Naour <romain.naour@openwide.fr>
2014-12-11 00:05:52 +01:00
Gustavo Zacarias
bf6f74de11 toolchain: add 3.18 choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-12-08 13:10:30 +01:00
Vicente Olivert Riera
8b3b60c96b toolchain-external: add CodeSourcery MIPS 2014.11, remove 2013.05
- Add CodeSourcery MIPS 2014.11 toolchain
- Remove CodeSourcery MIPS 2013.05 toolchain
- Update the hash file

Toolchain datasheet:
  https://sourcery.mentor.com/GNUToolchain/release2935?@template=datasheet

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-07 23:05:54 +01:00
Vicente Olivert Riera
68218a7c7f toolchain-external: fix the help message for CodeSourcery MIPS
- Fix the help message for CodeSourcery MIPS toolchains
- Add a hash file

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-07 23:05:46 +01:00
Yann E. MORIN
3e0440407a toolchain/external: fix building the wrapper on MIPS
Some crazy folks use MIPS machines as build machines. ;-)

On MIPS, the only acceptable hash-style is 'sysv', because the MIPS ABI
defines that the GOT ordering to be the same as the symbols ordering,
while GNU hash requires symbols to be sorted by their hash.

Looking at binutils' code, it seems that only MIPS suffers from that
limitation.

Currently, we force the toolchain wrapper to be linked with both hash
styles, which breaks on MIPS.

So, fix that by singling out MIPS, and use sysv in that case, and both
otherwise.

Reported-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-27 22:47:08 +01:00
Thomas Petazzoni
cce0add500 toolchain: do not allow locale generation when locale support is not available
When the C library being used is uClibc, the locale support can be
disabled. In this case, it does not make sense to show the "Generate
locales" option.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-21 21:50:59 +01:00
Thomas Petazzoni
bd0ffe2206 toolchain: do not allow BR2_GENERATE_LOCALE with musl
Generating locales is possible in two situations:

 - With the internal toolchain backend, when the uClibc library is
   used. With uClibc, locales are generated at build time of the C
   library, so with uClibc it's only possible with the internal
   toolchain backend.

 - With either the internal or external toolchain backend when the
   glibc library is used. With glibc, locales can be generated
   afterwards, using the host-localedef utility.

Until we had the musl C library supported in the internal toolchain
backend, the condition: BR2_TOOLCHAIN_BUILDROOT ||
BR2_TOOLCHAIN_USES_GLIBC was correct to capture the above two
situations. Now that we have musl support in the internal toolchain
backend, then BR2_TOOLCHAIN_BUILDROOT is incorrect, and we should use
BR2_TOOLCHAIN_BUILDROOT_UCLIBC instead.

Basic locale support in musl has appeared in musl 1.1.4, but we are
not yet capable of generating the locale files for musl.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-21 21:50:42 +01:00
Thomas Petazzoni
28bca1cef5 toolchain-external: update Linaro toolchains
Bump the ARM, ARMeb and AArch64 Linaro toolchains from 14.08 to
14.09. We can't bump to 14.10, because they completely changed the
toolchains and they are now completely broken: they switched from
Crosstool-NG to a new build tool to generate the toolchain, and now
the sysroot handling is completely borked.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-11 21:15:26 +01:00
Thomas Petazzoni
5715d2dcf4 toolchain-external: do not use BR2_GCC_TARGET_TUNE anymore
Since the BR2_GCC_TARGET_TUNE value is always empty now, there is no
longer a point in using it in the external toolchain logic.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-07 00:15:56 +01:00
Thomas Petazzoni
29f680644a toolchain-external: use BR2_ARM_CPU_ARM* options
Refactor the toolchain-external Config.in file to use the
BR2_ARM_CPU_ARM*. All of the changes are purely mechanical, except for
the Arago ARMv5 toolchain: it had a 'depends on BR2_GCC_TARGET_ARCH !=
"armv5t"', but armv5t was not a possible value for
BR2_GCC_TARGET_ARCH. Since the toolchain is ARMv5TE, the only ARM
architectures we need to exclude are ARMv4 and ARMv4T.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-06 23:59:05 +01:00
Gustavo Zacarias
e1eba3d97c system/skeleton: make nsswitch install conditional
Don't blindly install the /etc/nsswitch.conf file, it's useless for
toolchains that aren't (e)glibc-based and misleading.
Make the installation conditional on a (e)glibc toolchain.

[Thomas: use $(INSTALL) instead of cp.]

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-10-25 12:48:17 +02:00
Jerzy Grzegorek
595bf30654 package: indentation cleanup
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-10-23 22:13:29 +02:00
Karoly Kasza
b8f9e5771a toolchain: external 3.17 headers typo fix
Commit 2d312b7b61 had a typo
"." instead of "_" in BR2_TOOLCHAIN_HEADERS_AT_LEAST_3.17.
This made selecting 3.17 as custom external headers version
impossible.

Signed-off-by: Karoly Kasza <kaszak@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-09 13:25:23 +02:00
Thomas De Schampheleire
f268f7131b .mk files: bulk aligment and whitespace cleanup of assignments
The Buildroot coding style defines one space around make assignments and
does not align the assignment symbols.

This patch does a bulk fix of offending packages. The package
infrastructures (or more in general assignments to calculated variable
names, like $(2)_FOO) are not touched.

Alignment of line continuation characters (\) is kept as-is.

The sed command used to do this replacement is:
find * -name "*.mk" | xargs sed -i \
    -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*$#\1 \2#'
    -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\]\+\)$#\1 \2 \3#'
    -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\ \t]\+\s*\\\)\s*$#\1 \2 \3#'
    -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\(\s*\\\)#\1 \2\3#'

Brief explanation of this command:
    ^\([A-Z0-9a-z_]\+\)     a regular variable at the beginning of the line
    \([?:+]\?=\)            any assignment character =, :=, ?=, +=
    \([^\\]\+\)             any string not containing a line continuation
    \([^\\ \t]\+\s*\\\)     string, optional whitespace, followed by a
                            line continuation character
    \(\s*\\\)               optional whitespace, followed by a line
                            continuation character

Hence, the first subexpression handles empty assignments, the second
handles regular assignments, the third handles regular assignments with
line continuation, and the fourth empty assignments with line
continuation.

This expression was tested on following test text: (initial tab not
included)

	FOO     = spaces before
	FOO     =   spaces before and after
	FOO	= tab before
	FOO	  = tab and spaces before
	FOO =	tab after
	FOO =	   tab and spaces after
	FOO =   	spaces and tab after
	FOO =    \
	FOO = bar \
	FOO = bar space    \
	FOO   =		   \
	GENIMAGE_DEPENDENCIES   = host-pkgconf libconfuse
	FOO     += spaces before
	FOO     ?=   spaces before and after
	FOO     :=
	FOO     =
	FOO	=
	FOO	  =
	FOO =
	   $(MAKE1) CROSS_COMPILE=$(TARGET_CROSS) -C
	AT91BOOTSTRAP3_DEFCONFIG = \
	AXEL_DISABLE_I18N=--i18n=0

After this bulk change, following manual fixups were done:
- fix line continuation alignment in cegui06 and spice (the sed
  expression leaves the number of whitespace between the value and line
  continuation character intact, but the whitespace before that could have
  changed, causing misalignment.
- qt5base was reverted, as this package uses extensive alignment which
  actually makes the code more readable.

Finally, the end result was manually reviewed.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Yann E. Morin <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-07 15:00:28 +02:00
Gustavo Zacarias
2d312b7b61 toolchain: add 3.17 choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-06 16:24:32 +02:00
Thomas Petazzoni
a08dcf77a8 toolchain-external: bump ARM, ARMeb and AArch64 Linaro toolchains to 14.08
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-16 22:15:20 +02:00
Thomas Petazzoni
93f3c04a91 toolchain-external: remove CodeSourcery ARM 2012.03, add 2014.05
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-16 22:14:12 +02:00
Thomas Petazzoni
bab8f27a63 toolchain-external: add CodeSourcery AArch64 toolchain
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-16 22:13:12 +02:00
Gustavo Zacarias
e7d77fc36e toolchain/musl: disable for PowerPC SPE
It's not supported and the build breaks.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-13 22:02:01 +02:00
Ezequiel García
3ca5f0b49c toolchain-external: Add CodeSourcery Nios-II 2014.05
This new toolchain release fixes a number of issues found with the previous
one. In particular, the issues with fallocate64, prlimit64 and the
ill-installed linux headers seem to be fixed now.

Therefore, there's not need to sanitize the headers for this toolchain and some
packages should now build fine (e.g. fio).

Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-01 16:13:38 +02:00
Yann E. MORIN
6172ceb3cf toolchain: drop the now-unused old BR2_TOOLCHAIN_HAS_ATOMIC_INTRINSICS
It's now been replaced with BR2_ARCH_HAS_ATOMICS, annd all packages have
been changed to use that instead.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-08-18 10:57:55 +02:00
Yann E. MORIN
1b5f0fc8df arch: add an option to specify if the arch has atomic ops
The fact that atomic operations are available is not really a
specificity of the toolchain, but rather of the architecture.

So, add a new option that architectures that have atomic operations
can select. This in turn selects the current toolchain atomic option,
until all packages have been converted, at which point the old
toolchain option can be removed.

Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-08-18 10:56:35 +02:00
Gustavo Zacarias
911516f1b6 toolchain: add 3.16 choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-04 09:46:41 +02:00
Anton Kolesov
cbffd50561 toolchain: Add config option for atomic intrinsics
GCC has several builtin functions that implement atomic operations. Those
functions are architecture specific and may not be implemented by the
specific toolchain. In case of GCC for ARC those functions rely on
LLOCK/SCOND instructions which are optional in ARC CPU's. If ARC CPU doesn't
support those instructions but software tries to use them, then application
will be aborted with Illegal instruction exception. To avoid confusion user
should first specify that their CPU supports atomic extension, which will
allow selection of packages that use builtin atomic functions.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 11:20:47 +02:00
Yann E. MORIN
a930d9cef6 toolchain: linker options with a $ sign are not supported
As reported in bug #7172 [0], setting BR2_TARGET_LDFLAGS to a value
containing a $ sign can lead to unexpected results.

This is because it is very hard to know when the $ sign gets evaluated:
  - in the Buildroot-level make
  - in the shell called by the Buildroot-level make
  - in the package's own build-system, either at configure time, in the
    Makefile, in a shell in the Makefile...

So, it is very difficult to know how much escaping that would need.

A proposal is to use a shell variable to pass such values unmolested.
But it is not that simple either, since it still contains a $ sign, and
there is not much certainty as to when it would be evaluated.

Instead, just document this limitation, both in the help text for
BR2_TARGET_LDFLAGS, and in the known-issues section in the manual.

Does not really fix #7172, but at least the limitation is documented.

[0] https://bugs.buildroot.org/show_bug.cgi?id=7172

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Mike Zick <minimod@morethan.org>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-31 23:51:39 +02:00
Yann E. MORIN
11c1076db9 toolchain: add option to copy the gconv libraries
The gconv libraries are used to translate between different character sets
('charsets', even 'csets' sometimes). Some packages need them to present
text to the user (eg. XBMC Gotham).

In (e)glibc they are implemented by the internal implemenation of iconv,
called gconv, and are provided as dlopen-able libraries.

Note that some gconv modules need extra libraries (shared by more than
one gconv module), so we must, when adding a subset of modules, scan the
installed modules in search of the missing libraries.

[Thomas: add general explanation in expunge-gconv-modules and fix
coding style.]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Cc: Eric Limpens <limpens@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-27 23:15:48 +02:00
Thomas Petazzoni
1cfeed1a4d toolchain-external: remove experimental Blackfin toolchain
The 2014R1 toolchain is provided in two flavours by Analog Devices:
one based on gcc 4.3.x, which is considered stable, and one based on
gcc 4.5.x, considered experimental. In commit
5a65b8e185 ("toolchain-external: add ADI
Blackfin 2014R1 toolchain, remove 2012R1") both variants were added.

However, after some testing in the autobuilders, and discussion with
the Analog Devices folks, it turns out that the experimental version
of the toolchain is too experimental. It causes numerous build
failures, and the Analog Devices folks clearly say that it's an early
release and that they expect quite a few problems to show up.

Therefore, this commit removes the experimental flavor and keeps only
the stable variant. Note that the removal/renaming of the Config.in
options is not a problem, since those options were added after the
2014.05 release.

Fixes:

  http://autobuild.buildroot.org/results/2a9/2a9d9c332a206fdb46bc8ba022c74d23082a6312/
  http://autobuild.buildroot.org/results/e1c/e1ce0c1cdd0139208dddaa8f2441ab0e3ab2385e/
  http://autobuild.buildroot.org/results/993/993aca3f4719afaa4b37524f9136fb8cdc53a066/
  and more.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-07-10 11:30:25 +02:00
Baruch Siach
40ff839bc4 toolchain/helpers.mk: update check_arm_abi comment
Since commit b2e88073db (toolchain: check ARM EABI vs. EABIhf for external
toolchains), check_arm_abi accepts a second parameter. Update the comment
accordingly.

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-07-04 23:51:35 +02:00
Baruch Siach
8420d4c169 toolchain/helpers.mk: don't discard check_arm_abi stderr
Since we only need to know whether the compiler runs successfully, and
stderr is empty for the success case, there is no need to redirect stderr to
/dev/null. Moreover, stderr output of the failing case reveals valuable
information on the real failure reason.

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-07-04 23:21:49 +02:00
Thomas De Schampheleire
9a8ec9195c toolchain/toolchain-buildroot: migrate to virtual package infrastructure
This patch migrates the toolchain and toolchain-buildroot packages to the
virtual package infrastructure, causing the log messages to change from:

>>> toolchain undefined Downloading
>>> toolchain undefined Extracting
...

to

>>> toolchain virtual Downloading
>>> toolchain virtual Extracting
...

and similar for 'toolchain-buildroot', simply because it looks nicer.

At the same time, the directory names also become toolchain-virtual,
toolchain-buildroot-virtual instead of the corresponding 'undefined'
variants.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-14 19:10:13 +02:00
Thomas Petazzoni
20d4ba91c5 toolchain-external: add CodeSourcery PowerPC 2012.03
However, this toolchain is only usable for e500v2 with the SPE ABI.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
2014-06-14 19:04:50 +02:00
Thomas Petazzoni
5c8526691c toolchain-external: bump musl external toolchains to 1.1.1
And while we're at it, factorize the definition of the musl version,
since it's common to the definition of the tarball names for the
various supported architectures.

[Peter: Adjust Config.in info to match new version]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-13 14:50:03 +02:00
Thomas Petazzoni
5a65b8e185 toolchain-external: add ADI Blackfin 2014R1 toolchain, remove 2012R1
This commit adds support for two ADI Blackfin toolchains: the 'stable'
2014R1 based on gcc 4.3, and the 'experimental' 2014R1 based on gcc
4.5.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09 15:41:18 +02:00
Thomas Petazzoni
8b832193af toolchain-external: add CodeSourcery MIPS 2014.05, remove 2012.09
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09 15:40:28 +02:00
Thomas Petazzoni
419a09cbf1 toolchain-external: bump Linaro AArch64 toolchain to 2014.05
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09 15:39:54 +02:00
Thomas Petazzoni
ba1563f9cc toolchain-external: bump Linaro ARMeb toolchain to 2014.04
For some reason, there is no ARMeb toolchain available in the 2014.05
Linaro release.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09 15:39:43 +02:00
Thomas Petazzoni
a167f0f930 toolchain-external: bump Linaro ARM to 2014.05
The major changes are: switch to gcc 4.9 instead of 4.8, and switch to
glibc 2.19 instead of glibc 2.18.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09 15:39:24 +02:00
Thomas Petazzoni
d51025d392 toolchain-external: support only one Linaro AArch64 toolchain at a time
Linaro toolchains are released so frequently (every month) that it
doesn't make much sense to support 3 consecutive versions. So, like we
do for ARM big-endian, let's support only one version at a time.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09 15:39:09 +02:00
Thomas Petazzoni
be2abf23ce toolchain-external: support only one Linaro ARM toolchain at a time
Linaro toolchains are released so frequently (every month) that it
doesn't make much sense to support 3 consecutive versions. So, like we
do for ARM big-endian, let's support only one version at a time.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09 15:38:55 +02:00
Thomas Petazzoni
cb29907c12 toolchain-external: do not pass TOOLCHAIN_EXTERNAL_CFLAGS for kernel headers check
When getting the sysroot used for the kernel headers version check,
passing TOOLCHAIN_EXTERNAL_CFLAGS causes a problem when used with
multilib toolchains, where only the main sysroot has the header files,
and the other sysroots only have the libraries.

Since the kernel headers version used is normally the same for all
sysroots, this commit solves this problem by removing the
TOOLCHAIN_EXTERNAL_CFLAGS argument when calling
toolchain_find_sysroot, so that it returns the main sysroot, in which
<linux/version.h> can be found for the kernel headers version check.

Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09 15:37:54 +02:00
Thomas Petazzoni
4e4ed5631f toolchain-external: apply kernel headers check to non-custom toolchains
Since the introduction of the kernel headers Config.in options, the
external toolchain logic had a check for custom external toolchains to
verify that the kernel headers version entered by the user matches the
one of the toolchain. However, this check was not made for non-custom
external toolchains (i.e the built-in profiles, such as Linaro,
CodeSourcery and al.), making the assumption that the Buildroot
developers will do the right selection.

However, it is quite nice when bumping external toolchains to have
this automatic kernel headers version check, to ensure we select the
appropriate kernel headers version.

Therefore, this commit makes the kernel headers version check
applicable to non-custom external toolchains.

Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09 15:37:23 +02:00
Gustavo Zacarias
fb29afe2aa toolchain: add 3.15 choice for headers
[Thomas: fix BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_15 to select
BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14 and not itself.]

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-09 14:48:55 +02:00
Waldemar Brodkorb
f7a257365e reenable microblaze little endian for internal musl toolchain
The assumption that musl libc does not support microblaze
little endian mode is wrong. See
http://git.musl-libc.org/cgit/musl/tree/configure line
number 447-448.

Tested with qemu. Just revert previous commit as suggested by
Thomas Petazzoni.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-01 17:28:57 +02:00
Peter Korsgaard
27a5414804 Merge branch 'next'
Conflicts:
	package/gdb/Config.in.host

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-01 09:58:54 +02:00
Gustavo Zacarias
5777e3ffd9 glibc: doesn't build for PowerPC SPE
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-30 23:56:37 +02:00
Thomas Petazzoni
1a55542e98 toolchain-buildroot: only allow the selection of Musl for Microblaze BE
The Musl C library only supports Microblaze BE, not Microblaze LE, so
this commit adjusts the dependencies of the toolchain-buildroot
package to not allow the selection of Musl on Microblaze LE.

Cc: William Welch <bvwelch@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-30 23:27:58 +02:00
Thomas Petazzoni
77ef6a3a12 toolchain-external: restrict Musl external toolchain to Microblaze BE
As reported by William Welch <bvwelch@gmail.com>, the Musl external
toolchain provided by the musl-cross project is only Microblaze
big-endian. In fact, Musl seems to only support the big endian variant
of the Microblaze architecture, with the microblaze-* tuple.

This commit makes sure the Musl pre-built external toolchain provided
by musl-cross can only be selected for a big-endian Microblaze
configuration.

Reported-by: William Welch <bvwelch@gmail.com>
Cc: William Welch <bvwelch@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-30 23:27:16 +02:00
Cody P Schafer
7e674dfa4f powerpc: add powerpc64 and powerpc64le support
This enables powerpc64 and powerpc64le. Currently, le needs at least
glibc 2.19 and gcc 4.9.0. For gdb, 7.7.1 works (added in an earlier
patch).

[Peter: also disallow gcc 4.8 for ppc64le]
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-26 21:48:33 +02:00
Jeff Bailey
a426a91973 Add support for powerpc64le
This patch adds support for powerpc64le-linux-gnu.  This includes
needed patches to fakeroot and gmp.

gmp patch is from upstream HG tree.
fakeroot patch is from Ubuntu written by Adam Conrad.

Signed-off-by: Jeff Bailey <jeffbailey@google.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-25 23:24:09 +02:00
Thomas Petazzoni
41486e1be8 toolchain-external: fix Linaro 2014.02 symlink
In commit cd32da8f79
("toolchain-external: add Linaro ARM big endian toolchain") a mistake
was made, probably due to a rebase conflict that was incorrectly solved:
the call to the post install staging hook that creates the necessary
symbolic links for a root filesystem based on Linaro 2014.02 to work
was removed.

This commit reinstates this call, which should fix the problem
observed by Maxime Hadjinlian while using Linaro 2014.02.

Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-21 10:37:54 +02:00
Thomas Petazzoni
85082cab93 toolchain-external: Sourcery CodeBench ARM 2013.05 affected by PR58595
Fixes:

  http://autobuild.buildroot.org/results/6b3/6b342c2d101348e4d39285f45481e2aafa3d8b3f/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-12 23:53:05 +02:00
Stefan Sørensen
3787592063 toolchain-external: Fix EABIhf check
Currently the check for EABI/EABIhf toolchains looks for the
Tag_ABI_VFP_args attribute in the crt1.o file which gcc adds in an
EABIhf toolchain.
In uClibc, however, crt1.o is not compiled from c but assembly, so the
Tag_ABI_VFP_args attribute is not added in the object file. This causes
the EABIhf check in the external toolchain logic to fail for
uClibc-based toolchains.

Fix by compiling a dummy .c file and trying to link the object against the
C library. Since it is impossible to mix EABI and EABIhf code, a mismatch
between the buildroot and toolchain ABI settings will be detected during
this link step.

Fixes bug #6842: https://bugs.busybox.net/show_bug.cgi?id=6842

[Peter: fix final 'fi']
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
[ThomasDS: do full link iso readelf test, update commit message]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-11 21:22:04 +02:00
Gustavo Zacarias
ff69b4a6e5 toolchain: remove nommu option for MIPS
MIPS nommu never took off, the only MIPS processors without MMU are
microcontrollers and the only uclinux effort for them has non-upstream
patches against very very old versions.
See http://www.xiptech.com/uclinuxformips.htm

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-08 16:53:15 +02:00
Gustavo Zacarias
493b1177b9 toolchain/buildroot: default to uClibc
Otherwise we're getting musl for everything except those who have a
default (mips64*).

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-06 14:06:01 +02:00
Thomas Petazzoni
2d71c1249f toolchain-external: add publicly available musl toolchains
This commit adds ten toolchains based on the musl C library that are
publicly available from the musl-cross project.

[Peter: fix ppc prefix, only for classic ABI]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-06 10:18:51 +02:00
Thomas Petazzoni
a84f478d3c toolchain-buildroot: add support for building musl toolchains
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-05 23:53:18 +02:00
Thomas Petazzoni
7130ceb267 toolchain: generate a gdbinit file
This commit slightly improves the external toolchain backend, and the
gdb build logic to create a file named
$(STAGING_DIR)/usr/share/buildroot/gdbinit which can be used as a
gdbinit file using gdb -x option. This allows gdb to automatically use
the proper sysroot to find libraries.

The initial insight for this patch comes from the report of Oded
Hanson <OHanson@xsightsys.com>, who found an issue with the Eclipse
Buildroot plugin, which was setting a solib-path in gdb, but not a
sysroot. Setting a solib-path was enough to find shared libraries, but
not the dynamic linker. And since Eclipse doesn't allow to set the
sysroot in any other way than giving a gdbinit file, it makes sense to
have Buildroot generate a gdbinit file (which can be used in other
situations than Eclipse).

To achieve this, this commit introduces a gen_gdbinit_file helper in
toolchain/helpers.mk, and uses it for the internal toolchain and
external toolchain backends.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[ThomasDS: minor updates in commit message]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-05 13:31:30 +02:00
Gustavo Zacarias
97b25caecd toolchain: enable internal for aarch64
Enable the internal toolchain backend for aarch64.
Tested with arm_foundationv8_defconfig and ARMs foundation v8 emulator.
Both glibc & eglibc work.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-04-24 15:21:13 +02:00
Fabio Porcedda
5f70a007c8 toolchain: add a hidden config option to enable the toolchain package
The usual way to enable a package using the package infrastructure is to
use a config option so instead to add the toolchain package to the
TARGETS variable in the Makefile add a config option like all the other
toolchain packages.

[Thomas: remove comment that no longer made sense in the main
Makefile, and add a comment above the new hidden Config.in option to
explain what it is useful for.]

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-16 19:37:08 +02:00
Thomas Petazzoni
cd32da8f79 toolchain-external: add Linaro ARM big endian toolchain
Linaro has started to release ARM big endian toolchains, so we
integrate this toolchain in the external toolchain logic of
Buildroot. Since ARM big endian is probably going to be a lot more
uncommon than ARM little endian, we will only support one version at a
time of this toolchain.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14 23:10:38 +02:00
Thomas Petazzoni
0d740d8195 toolchain-external: bump Linaro AArch64 toolchains
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14 23:09:32 +02:00
Thomas Petazzoni
6283788656 toolchain-external: remove useless info in help text of Linaro ARM toolchains
The information "To use this toolchain, you must disable soft float
usage." which was visible in the help text of Linaro toolchains is no
longer useful, since those toolchains are only visible when the ARM
EABIhf ABI is selected, which by design is not compatible with
soft-float.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-04-14 23:08:22 +02:00
Thomas Petazzoni
d2c54e603c toolchain-external: bump Linaro ARM toolchains
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14 23:07:57 +02:00
Ezequiel García
e48ef3f522 toolchain-external: Introduce kernel headers sanitization
The Nios-II Sourcery external toolchain (the only Nios-II we currently
support) exports broken kernel headers. In particular, these kernels should
be exported using the "headers_install" rule which applies a set of fixes
on the kernel headers so they are suitable for userspace usage.

In order to fix this, add a post-install hook to perform the header fixes
ourselves. The result is equivalent to apply the "headers_install" rule.

Fixes:
http://autobuild.buildroot.net/results/c32/c32ad4bac5f651502e551f7733f702afaa0e742a/

Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14 22:40:21 +02:00
Thomas Petazzoni
be4f30a4ff toolchain: add option to declare toolchains affected by gcc PR 58595
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14 22:37:48 +02:00
Baruch Siach
5c76842107 ext-toolchain-wrapper: fix typo
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-04-10 22:24:30 +02:00
Yann E. MORIN
2a82bb8a90 support/check-kernel-headers: fix old custom toolchains without -print-sysroot
Old toolchains, with old gcc that do not support -print-sysroot, break the
kernel-headers version check script: it fails to find the sysroot of the
toolchain, and thus ends up including the host's linux/version.h.

Most of the time, this will break early, since the host's kernel headers
will not match the toolchain settings.

But it can happen that the check is succesful, although the configuration
of the toolchain is wrong:

  - the custom toolchain has kernel headers vX.Y
  - the user selected vX.Z  (Z!=Y)
  - the host has headers vX.Y

In this case, the check passes OK, but the build of some packages later on
will break (which is exactly what those _AT_LEAST_XXX options were added to
avoid).

Fix that by passing the sysroot to the check script, instead of the cross
compiler.

We get the sysroot as thus:

  - for custom toolchains, we use the macro toolchain_find_sysroot. We can
    do that, because we already have a complete sysroot with libc.a at that
    time.

  - for internal toolchain using a custom kernel headers version, we just
    use $(STAGING_DIR). We can't use the macro as for custom toolchains
    above, because at the time we install the kernel headers, we do not yet
    have a complete sysroot with a libc.a.  But we can just use
    $(STAGING_DIR), since we're only interested in the kernel headers.

For all other types of toolchains, we already have the _AT_LEAST_XXX options
properly set, so we need not add a check in this case.

Fixes:
    http://autobuild.buildroot.net/results/f33/f331a6eff0b0b93c73af52db3a6b43e4e598577e/
    http://autobuild.buildroot.net/results/a57/a5797c025bec50c10efdcff74945aab4021d05e4/
    [...]

[Thanks to Thomas for pointing out the toolchain_find_sysroot macro!]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-04-09 01:38:10 +02:00
Samuel Martin
11547ca648 external toolchain: add 3.14 choice for kernel headers
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-04-07 00:46:27 +02:00
Yann E. MORIN
0aa9019c2d toolchain: print actual version of kernel headers when checking
Since we introduced the _AT_LEAST_XXX for the kernel headers, people
using pre-built custom toolchain now have to specify the version of
the kernel headers their custom toolchain uses.

So, when we detect that there is a mismatch between the selection in
the menuconfig, and the actual version of the headers, we currently
only bail out with a terse message "Incorrect selection of kernel
headers".

This could be confusing some, and getting the version of the headers
used by the toolchain is not trivial (well, it's very easy, but not
trivial.)

This patch changes the way we report the error by moving the message
into the test-code, and by printing the expected and actual versions
of the kernel headers.

BUT! To get this pretty error message, we need to run the
test-program, so we can not use the cross-toolchain, we have to use
the native one.

BUT! The native one has its own linux/version.h header, so we can not
simply include it.

So, we ask the cross-compiler where its default sysroot is, and use
that to then force-feed the cross linux/version.h to the native
toolchain.

[Thomas: augment commit log with a message provided by Yann, fix
coding style to not have spaces after opening parenthesis and before
closing parenthesis, reformatted the message "Incorrect selection..."
to make it fit on one line.]

Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-06 14:26:34 +02:00
Noam Camus
65c2400ff2 toolchain: control vendor part in GNU_TARGET_NAME
This option allows to customize the "vendor" part of the
toolchain tuple, where the toolchain tuple has the form
<arch>-<vendor>-<os>-<libc>. Use this option in situations
where gcc might make different decisions based on the vendor
part of the tuple.

[Thomas: move the config option in a slightly different place, so that
it does not appear between the C library selection and the C library
options.]

Signed-off-by: "Noam Camus" <noamc@ezchip.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-06 14:16:06 +02:00
Gustavo Zacarias
4916b889e2 linux-headers: add 3.14, bump 3.{4, 10, 13}.x series
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-01 14:44:27 +02:00
Samuel Martin
a1a86ebfba liburcu: disable build with gcc-4.8.x on ARM
Because of a gcc bug [1], liburcu checks for compiler version [2] and
stops the build prematurely if gcc-4.8.[0-2] is detected for ARM.

However a bug fix exists [3] and may be backported by ARM toolchain
providers; that's what is done in Buildroot [4] or Linaro [5].

So, this change:
- add a patch in liburcu to allow build with ARM gcc-4.8.2;
- adds a new hidden symbol to reflect the toolchain status with regard
  to this bug [1];
- and controls liburcu visibility.

However, a limitation of this is when the user is using a custom
toolchain; that's why the bug details have been added in the liburcu
help message.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
[2] http://git.lttng.org/?p=userspace-rcu.git;a=commitdiff;h=4b79310
[3] http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=204665
[4] http://git.buildroot.net/buildroot/commit/?id=c443c2be1768ebbdcb76c55d0a08fd7c983488c8
[5] http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.8/revision/122147

[Peter: hide normal toolchain comment if bug, add comment explaining issue if bug]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-03-23 23:17:56 +01:00
Thomas Petazzoni
b60b6f660d toolchain-external: Linaro AArch64 toolchains need a symlink, like ARM ones
Like ARM ones, the Linaro AArch64 toolchains expect libraries in
/lib/aarch64-linux-gnu and /usr/lib/aarch64-linux-gnu, but Buildroot
always installs them in /lib and /usr/lib. Therefore, this commit adds
the appropriate symbolic links, just like we're already doing for
Linaro ARM toolchains.

Reported-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-03-21 07:27:03 +01:00
Thomas Petazzoni
e4644b611c toolchain-external: fix musl external support on x86
On x86, the symbolic link ld-musl-<ARCH>.so.1 to libc.so must be
ld-musl-i386.so.1 in all cases, but $(ARCH) in Buildroot might be
i386, i486, i586, i686, etc. depending on the specific x86 variants
being selected.

This commit fixes that by creating a MUSL_ARCH variable set to i386 on
x86, and to $(ARCH) on other architectures.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2014-03-06 22:59:48 +01:00
Yann E. MORIN
35c666e29b toolchain/wrapper: rename BR_DEBUG_WRAPPER
The user-facing variables should be prefixed with BR2_, not BR_.

Also quote the variable in the manual.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-05 19:46:31 +01:00
Yann E. MORIN
71516ab9e8 glibc: needs MMU
Like eglibc, glibc is only available to MMU-based architectures.

Re-order select/depends to be in-line with eglibc, just above.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-03 21:26:56 +01:00
Yann E. MORIN
a5a309642a toolchain/external: check kernel headers version for custom toolchain
Ensure the kernel headers version used in the custom external toolchain,
or the manually-specified kernel headers version, matches exactly the one
selected by the user.

We do not care about the patch-level, since headers are not supposed to
change between patchlevels. This applies only to kernels >= 3.0, but
those are actually the ones we do care about; we treat all 2.6.x kernels
as being a single version, since we do not support any 2.6 kernels for
packages with kernel-dependant features.

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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-01 19:47:22 +01:00
Yann E. MORIN
c58bcd5dfb toolchain/external/custom: add choice to select 'AT_LEAST_XXX' header version
Select the appropriate BR2_TOOLCHAIN_HEADERS_AT_LEAST_XXX options for the
external, custom toolchain backend.

We try to be conservative here, and default to kernel headers 2.6.x.

[Thomas: remove duplicated depends on BR2_TOOLCHAIN_EXTERNAL_CUSTOM,
since the choice is already inside a if BR2_TOOLCHAIN_EXTERNAL_CUSTOM
... endif block.]

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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-01 17:16:52 +01:00
Yann E. MORIN
b6f321b1c6 toolchain/external/predefined: add choice to select 'AT_LEAST_XXX' header version
Select the appropriate BR2_TOOLCHAIN_HEADERS_AT_LEAST_XXX options for the
external, pre-defined toolchains.

Also annotate those toolchain with older-than-3.0 headers.

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>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-01 17:15:38 +01:00
Yann E. MORIN
b155f5a5ab toolchain/common: add minimum kernel headers options
We now have quite a few packages that depend on the kernel headers to be
at least a certain version. For example, dvb-apps requires at least the
3.3 kernel headers.

Add a set of options that packages can depend on, to check that the kernel
headers match their required version.

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>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-01 17:15:09 +01:00
Thomas Petazzoni
c64f948d2c toolchain: introduce a toolchain knob for NPTL
As our architecture support expands to a number of architectures that
do not implement NPTL threading, and the number of packages that
depend on NPTL specific features, it has become necessary to be able
to know whether the toolchain has NPTL support or not.

This commit adds a new BR2_TOOLCHAIN_HAS_THREADS_NPTL hidden Config.in
option that allows packages to know whether NPTL is available or not.

This hidden option is:

 * Automatically enabled when glibc/eglibc or musl toolchains are
   used, either internal or external.

 * Automatically enabled when an internal uClibc toolchain with NPTL
   support is configured. It is left disabled otherwise for internal
   uClibc toolchains.

 * Configured according to a visible Config.in option for custom
   external uClibc toolchains.

[Peter: factor _EXTERNAL_HAS_THREADS in single if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-22 23:39:01 +01:00
Fabio Porcedda
b2fd9f90e2 package: add toolchain dependency to every target package
This commit makes the dependency from the target toolchain explicit.
This way we can buid from command line a package that use
inner-generic-package right after the configuration phase, example:

	make clean <package-name>

Also remove TARGETS_ALL because the only purpose was to add toolchain
dependency so it's superseded by this commit.

To prevent circular dependency add the new variable
<pkgname>_ADD_TOOLCHAIN_DEPENDENCY to avoid adding the toolchain
dependency for toolchain packages.

This is also a step forward supporting top-level parallel make.

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-14 21:08:35 +01:00
Fabio Porcedda
6f13130ac9 package: add base dependency to every package
Move "dependencies" "dirs" "prepare" dependencies from "toolchain" to
every package.
This way we can build correctly every package right after the clean
stage.
As example with this commit we can build successfully the glibc right
after the clean stage:
	make clean glibc

This is also a step forward supporting top-level parallel make.

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-14 21:08:19 +01:00
Thomas Petazzoni
6762e427db glibc: add 2.19 as a supported version
glibc 2.19 has been released recently
(https://sourceware.org/ml/libc-alpha/2014-02/msg00224.html). This
commit allows to build a toolchain with this new version. In order to
allow this, we add a version selection that did not exist for
glibc. We default to 2.18, which was the only supported version until
now, and add an option for 2.19.

For microblaze, which uses a specific glibc version, the version
selection choice is not displayed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-13 22:22:54 +01:00
Peter Korsgaard
de13e31a16 Rename BUILDROOT_LIBC to BR_LIBC
No functional change, but internal variables should be name BR_foo, not
BUILDROOT_foo (I think ..).

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-04 15:06:46 +01:00
Adrien Béraud
a20cb38659 arch: add support for "jaguar" AMD CPU optimisations
AMD Jaguar ( https://en.wikipedia.org/wiki/Jaguar_%28microarchitecture%29 ) is
suddenly a popular architecture since it is used in the PS4 and the XBox One.
Many embedded systems are also likely to use it in the next years.

This patch adds support for GCC architecture-specific optimisations and
tuning for these CPUs.
These optimizations are available with GCC 4.8+.

Signed-off-by: Adrien Beraud <adrien.beraud@savoirfairelinux.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-15 23:19:46 +01:00
Stefan Sørensen
803a105f90 toolchain-external: Fix ld.so naming with uClibc and EABIhf.
Currently ld-linux-armhf.so.* is added to external libs when
using an EABIhf toolchain, but this naming is not used by uClibc.
Fix by adding a check for glibc.

Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-15 22:52:33 +01:00
Thomas De Schampheleire
ba4ad9d27c deprecated handling: introduce BR2_DEPRECATED_SINCE_xxxx_xx
In order to keep better track of when a feature got deprecated, and hence
when it can be removed, a new set of symbols BR2_DEPRECATED_SINCE_xxxx_xx is
introduced. These symbols are automatically selected when BR2_DEPRECATED is
selected, and thus are transparent to the user.
A deprecated feature will no longer depend on BR2_DEPRECATED directly, but
rather on the appropriate BR2_DEPRECATED_SINCE_xxxx_xx. If that symbol does
not yet exist, it has to be created in Config.in.
When removing a deprecated feature, one should also check whether this was
the last feature using the BR2_DEPRECATED_SINCE_xxxx_xx symbol, in which
case the latter can be removed from Config.in.

A followup patch will make sure the overview is added to the list of
deprecated features in the manual, so that a buildroot core developer can
easily determine which features to remove in a given development cycle.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-10 15:03:53 +01:00
Yann E. MORIN
2c1dc32647 toolchain/external: fix wrapper by not passing conflicting flags
In our wrapper, we forcibly add the -march=, -mcpu= and-mtune= flags
to the actual compiler, this in an attempt to always generate correct
and optimised code for the target.

But in some cases, the caller knows better than we do, and passes its
own set, or subset of those flags. In this case, some may conflict with
the ones we pass. The most prominent offender being the Linux kernel.

For example, on the ARM Raspberry Pi, the Linux kernel will set the
-march=armv6 flag and no -mcpu= flag, but we pass -mcpu=arm1176jzf-s,
which conflicts:

    drivers/scsi/scsi_trace.c:1:0: warning: switch -mcpu=arm1176jzf-s
    conflicts with -march=armv6 switch

(and so for all the files the kernel compiles, pretty messy)
(note: arm1176jzf-s is not an armv6, it is an armv6zk. Yeah...)

To avoid this situation, we scan our commandline for any occurence of
the possibly conflicting flags. If none is found, then we add our owns.
If any is found, then we don't add any of our owns.

The idea behind this is that we trust the caller to know better than
we do what it is doing. Since the biggest, and sole so far, offender
is the Linux kernel, then this is a rather safe bet.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-09 21:17:35 +01:00
Jerzy Grzegorek
3033bc0c6e package: remove the empty trailing line(s)
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-04 10:39:29 +01:00
Thomas Petazzoni
951fc4c63f toolchain-external: add support for the Blackfin 2013R1 toolchain
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-12-31 00:19:13 +01:00
Thomas Petazzoni
89be0985d6 toolchain-external: mark Microblaze external toolchains as deprecated
The Xilinx Microblaze external toolchains that we had support for are
very old, and are causing a huge number of build issues. Thanks to
Spenser Gilliland, we now have support for Microblaze in the internal
toolchain backend, and the autobuilders have been using the internal
toolchain backend since then. Therefore, it's time to deprecate those
old and unusable external toolchains.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-12-31 00:19:06 +01:00
Thomas Petazzoni
68b967a985 toolchain-external: update Linaro AArch64 toolchains
Add Linaro AArch64 2013.10 and Linaro AArch64 2013.11, and remove
Linaro AArch64 2013.07 and Linaro AArch64 2013.08.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2013-12-31 00:19:00 +01:00
Thomas Petazzoni
34562eec83 toolchain-external: update Linaro ARM toolchains
Add Linaro ARM 2013.10 and Linaro ARM 2013.11, and remove Linaro ARM
2013.07 and Linaro ARM 2013.08.

The main change for those versions is the switch to eglibc 2.18.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-12-31 00:18:54 +01:00
Thomas Petazzoni
245686ffb3 toolchain-external: add Sourcery MIPS 2013.11, remove Sourcery MIPS 2012.03
This commit adds the support for the recently release Sourcery MIPS
2013.11 toolchain (gcc 4.8, gdb 7.6, glibc 2.18), and consequently
removes the support for the Sourcery MIPS 2012.03 toolchain.

While we're at it, also fix the incorrect help text related to the
MIPS64 multilib selection.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2013-12-31 00:17:06 +01:00