binutils/binutils: simplify gold dependencies

In preparation of adding a new kernel-type, Yann D. came up
with a change in semantic on binutils/gold availability.

So far, it was architectures' responsibility to declare that
they did support binutils/gold or not. It makes much more sense
that binutils/gold declares its own availability depending on
the current architecture; after all, architectures have no way
to know wether gold supports them, while gold does know it.

Signed-off-by:Yann Diorcet <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: split up original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <d3d1d51f399e6d2c1163.1353320546@macbook-smorlat.local>
Patchwork-Id: 199971

binutils: cleanup ELF/FLAT/FDPIC dependencies

In preparation of adding a new kernel-type, Yann D. came up
with a cleanup pass on the ELF/FLAT/FDPIC dependencies.

Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: split up original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <d3d1d51f399e6d2c1163.1353320546@macbook-smorlat.local>
Patchwork-Id: 199971

scripts: add BUILD/HOST extra cflags/ldflags

On some hosts, and for certain toolchains (eg. toolchain targetting
the upcoming Darwin), it may be necessary to pass arbitrary CFLAGS
and/or LDFLAGS when building the components.

And necessary infrastructure:
- EXTRA_{CFLAGS,LDFLAGS}_FOR_{BUILD,HOST} as config options
- pass those extra flags to components

Fix-up a slight typo in elf2flt at the same time (misnamed cflags).

Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <d24043276c9243a35421.1353077450@macbook-smorlat.local>
Patchwork-Id: 199645

scripts: unquoted variable reference in glibc-eglibc.sh-common

Signed-off-by: Daniel Price <daniel.price@gmail.com>
Message-Id: <12f092a95a94bcf76912.1353367250@redfish.dssd.com>
Patchwork-Id: 200215

binutils/sstrip: remove

sstrip has been obsoleted for a while now, as it's still broken
for some archs, and there seems to be no incentive to fix it
upstream. Besides, the space gained with sstrip is marginal at
best.

Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <65c8bf534d0647ce52cd.1353320545@macbook-smorlat.local>
Patchwork-Id: 199970

binutils/binutils: do not fwd declare struct stat (2.22).

For canadian cross to host i686-mingw32 fwd declaring
struct stat is not possible.
Instead #include <sys/stat.h>

Signed-off-by: Titus von Boxberg <titus@v9g.de>
Message-Id: <417a15d4277913841ddd.1353100974@tschetwerikow.boxberg.lan>
Patchwork-Id: 199733

complibs: introduce generic multi-complibs infrastructure

Use the same method as companion tools for providing generic and
extendable companion libs.

Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <515c5c4635d99ebe4877.1353074410@macbook-smorlat.local>
Patchwork-Id: 199613

kernel/linux: update revisions

Update Linux with the latest available revisions.

Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <4b669b1e51901b6ec6b1.1353009148@advdt005-ubuntu>
Patchwork-Id: 199394

cc/gcc: update Linaro GCC revisions to 2012.11

Update Linaro GCC with the latest available revisions.

Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <8e49233e63d9d6051dc2.1353008548@advdt005-ubuntu>
Patchwork-Id: 199390

libc/mingw: replace mingw32 with generic mingw

Replace the 32-bit-only mingw32 with mingw-w64 that is capable
of building toolchains for both 32-bit and 64-bit Windows.

kernel/mingw: replace mingw32 with generic Windows
kernel/windows: New windows kernel supporting 32 and 64 bit arch
libc/mingw: Remove old options
patches: Remove old mingw libc options' patches

Signed-off-by: "Yann Diorcet" <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: array var in libc/mingw.sh, typos]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <b045ac08fc9eac2e5ee3.1352898499@blackmint>
Patchwork-Id: 198901