scripts/functions: add target_endian_le and target_endian_be

We currently define target_endian_el and target_endian_eb to be the
tuple extension depending on endianness, defined to be respectively
'el' or 'eb' according to the endianness.

Some architecture do not use 'el' or 'eb', but use 'le' or 'be'.

Provide that as well, as two new variables: target_endian_le and
target_endian_be.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Cody P Schafer <dev@codyps.com>

cc/gcc: add 4.9.0

Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: latest is now a 4.9]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <5bac788539bb272893ed.1399801933@gun>
Patchwork-Id: 347774

complibs/ppl: Fix build of ppl 0.11.2 with gcc 4.9

From: Roberto Bagnara <bagnara@cs.unipr.it>
Date: Tue, 29 Apr 2014 19:51:43 +0000 (+0200)
Subject: Added missing inclusions. Use std::ptrdiff_t.
X-Git-Url: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl%2Fppl.git;a=commitdiff;h=61d4e14dfd9f1121e9b4521dead5728b2424dd7c

Added missing inclusions. Use std::ptrdiff_t.
(Thanks to Paulo Cesar Pereira de Andrade.)

Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Message-Id: <5632a171e7c1dc4c0fb5.1399806148@euler.fritz.box>
Patchwork-Id: 347777

binutils/elf2flt: restore the custom location functionality

Somehow, it got lost when incorporating elf2flt in the binutils farmework.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

binutils/binutils: do not forget to extract elf2flt

In case we're using a custom (aka local) binutils source, we still
need to extract and patch elf2flt.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

binutils/elf2flt: use alternate mirror

The official elf2flt upstream has disapeared.

Switch to a mirror.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

functions: finally fix the git helper

It's gonna soon be used by elf2flt, so we better get it working.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

config: switch cc with libc in the config order

Some of the compiler options depend on the C library choice, (e.g.
whether core passes are needed).

Since the compiler menu comes before the C library menu, those options
may or may not be visible until the C library is chosen, leading to
either options being visible by the user (thus be puzzling as they would
not apply to his case), or invisible to him (yet again puzzling him).

Invert the order of the compiler and the C library in the menuconfig. It
anyway looks more rational, in the end.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

cc/gcc: allow CC_EXTRA_CONFIG_ARRAY on baremetal

The final bare-metal compiler is built using the core backend.
Currently the core uses the CC_CORE_EXTRA_CONFIG_ARRAY variable.

While this works as supposed to, this can leave the user puzzled
in the menuconfig, since all he can see is the core options, not
the final options.

Only show the core options if any of the core passes are needed,
and use the final options in the core-backend if we're issuing
the bare-metal compiler.

Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: hide core options if no core pass needed;
use final option in core backend if issuing the bare-metal compiler]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <22181e546ba746202489.1399688067@localhost>
Patchwork-Id: 347586

cc/gcc: avoid passing --enable-multilib

Some versions of gcc have a broken --enable-multilib flag. As multilib is the
default, only pass the --disable-multilib flag

Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: make it an if-block; duplicate commit log as comment]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <5c970c1ceb22528fe28a.1399687923@localhost>
Patchwork-Id: 347585

arch: add option to let gccdecide what floating point to use

Add an ARCH_FLOAT_AUTO option to avoid passing float options
to gcc and allow it to choose

Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: slightly reword the commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <088489641f4790262685.1399687813@localhost>
Patchwork-Id: 347584

debug/gdb: simplify the dependency logic

Signed-off-by: Cody P Schafer <dev@codyps.com>
Message-Id: <1d9659fcf6a9c7694ad2.1399687691@localhost>
Patchwork-Id: 347583

scripts: remove references to curl

It's been a while we're not using curl anymore.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

scripts: add possibility to not override default connection timeout

Allow '-1' to be specified as CONNECTION_TIMEOUT to disable the use
of the connection timeout for wget.

Signed-off-by: Cody P Schafer <dev@codyps.com>
Message-Id: <cb33f8c2cbaf802d4f04.1399687632@localhost>
Patchwork-Id: 347582

TODO: remove some items

Those items have now been implemented:

- mingw32 target
we have it now, and even mingw64 too

- mingw32 host
it is certainly possible to canadian-build a toolchain to run
in a mingw host

- Cygwin host
it is possible to build a toolchain in Cygwin, and it is probably
possible to canadian-build it as well

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

kernel/linux: update linux kernel headers

update linux kernel headers to a newer version

Signed-off-by: '"Daniel Zimmermann" <netzimme@gmail.com>'
[yann.morin.1998@free.fr: further bump the versions]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <424a44a11e7051d8d894.1392963455@haus-VirtualBox>
Patchwork-Id: 322417

scripts: Update config.guess and config.sub

Update config.guess and config.sub from:
http://git.savannah.gnu.org/gitweb/?p=config.git

Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: further update]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <befa8e8e81336bc1c415.1393054644@Bryans-MacBook-Pro.local>
Patchwork-Id: 323128

patches/binutils: Update patches from 2.22 to 2.24

This updates the patches in 2.22 to 2.24.
Some removed as they were applied upstream.

Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Message-Id: <9fb77800ae1d5f14cbf5.1393055637@Bryans-MacBook-Pro.local>
Patchwork-Id: 323130

newlib: fix extract process for custom version

newlib: fix extract process for custom version

If the user specifies the use of a custom newlib version, the logic in the
extract function was reversed, so this step would fail.

Signed-off-by: Trevor Woerner <trevor.woerner@linaro.org>
[yann.morin.1998@free.fr: keep leading indentation]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <c727adf1b7bd2c1e891d.1393353347@openSUSE-i7>
Patchwork-Id: 324060

libc/newlib: only requires core pass-2

Reported-by: Trevor Woerner <trevor.woerner@linaro.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

cc/gcc: only build required core passes

We now know exactly what pass to build, so build only what is required.

Reported-by: Trevor Woerner <trevor.woerner@linaro.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

cc: add options to differentiate the need for pass-1 and pass-2

In some cases, building the core pass-1 is unneeded, as the C library
will not try to build anything when installing headers, or sill not
install anything at all.

This is for example the case for newlib, wihch does not require a core
pass-1 since it builds nothing and installs no header.

This should also be the case for newer glibc-es with newer gcc-es,
which no longer require a core pass-1, since the circular dependency
glibc <-> gcc (about TLS?) has been resolved.

Reported-by: Trevor Woerner <trevor.woerner@linaro.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

configure: look for more usual g-variants of some tools

Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

configure: prefer g-variants

For awk and make, we currently check the standard names as found on
a classic GNU-userland system, and then fallback to looking for the
g-named variants as found on a *BSD system.

But it happens that the usual name might also be available on a *BSD
system, so we should first check the g-variant.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

configure.ac: respect 'g' variants of libtool/libtoolize

BSD OS'es (OS X for me) provide GNU tools with prefixed 'g'. To find correct
versions of libtool/libtoolize on those systems search also for
glibtool/glibtoolize.

Signed-off-by: Andreas Bießmann <andreas@biessmann.de>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: search for the g-variant first]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <2f1530b54afcb6a00e1d.1395158786@andreas-mbp.er.biessmann.org>
Patchwork-Id: 331467

cc/gcc: fix the PR58595 patch

It applies manually with fuzz 2, but ct-ng does not accept any fuxx at all.

So, re-diff the patch so it applies cleanly.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

cc/gcc: add some bug fixes to gcc 4.7.3 and 4.8.2

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

comptools: do not force build of make-3.81 unless really needed

On systems with make-3.82, we forcibly force the build and the use
of make-3.81

But some newer tools break when building with make-3.81. For example,
eglibc-3.18 breaks.

Introduce a new blind options that tools may select if they require
make-3.81. If the system does not have make-3.81, and this option is
selected, then we force the build of make-3.81. Otherwise, we leave
it to the user to decide on his own.

Note that no component selects this option for now. It will come in
later patches as we find them.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

If GNU make 3.81 is not found then build it as a companion tool.

Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
[yann.morin.1998@free.fr: add message "checking for make 3.81"]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <8b8bf6998f3d239f6c74.1392920971@advancedsearch.virginmedia.com>
Patchwork-Id: 322302

Companion tools are no longer experimental

Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Message-Id: <3e204a5cf9648db53a6a.1392920970@advancedsearch.virginmedia.com>
Patchwork-Id: 322301