Added tag crosstool-ng-1.5.2 for changeset bb01f4294cf2

1.5: update version string to 1.5.2

Fix typos and adjust some documentation.
(transplanted from 19205498184e299fb45a4addebcf7b480f119165)

libc/uClibc: add new patch to fix NULL pointer dereference
(transplanted from 3d8f6d826f21342b6172813384f3e5e1f09e8a71)

scripts: fix updating config.{sub,guess}
(transplanted from 7f52e1cca71eecc6a46ad1905afea42a5c8f0a68)

libc/uClibc: fix building on system with recent glibc

While trying to build a toolchain with ct-ng 1.5.0,
arm-unknown-linux-uclibcgnueabi target,
I get the following error:

[INFO ] Installing C library headers
[EXTRA] Copying sources to build dir
[EXTRA] Applying configuration
[EXTRA] Building headers
[EXTRA] Installing headers
[ERROR] extra/scripts/unifdef.c:209: error: conflicting types for 'getline'
[ERROR] make[2]: *** [extra/scripts/unifdef] Error 1
[ERROR] Build failed in step 'Installing C library headers'

The following patch solves the problem.
(It's a backport of this uClibc commit:
http://git.uclibc.org/uClibc/commit/?id=49e81cada73616864b9b31df0aeb6961c30f5a6e
)

[--SNIP from another mail--]
AFAIK this is a problem since glibc 2.10.
(transplanted from 1ba79f2126df8bd89120899a58f2d0bcc2e9c771)

libc/newlib: fix host/target confusion

newlib handles the build/host/target a bit differently as one would expect:
build : not used
host : the nachine that builds newlib
target : the machine on which newlib will run
(transplanted from 3ccb1f76576fc7b730c57a0d1e183bce20cc47c0)

Fix typos and adjust some documentation.

Adding kernel 2.6.31.6 and 2.6.27.39

libc/glibc: configure libc headers with support for 128-bit long double

At the headers install pass, there's no compiler to test for the size
of long double. Help it: we know that the compiler does support 128-bit
long double, in the IBM extended precision.

Kindly pointed out, and explained, by Mike FRYSINGER:
http://sourceware.org/ml/crossgcc/2009-11/msg00040.html
http://sourceware.org/ml/crossgcc/2009-11/msg00057.html

libc/uClibc: add new patch to fix NULL pointer dereference

libc/uClibc: add wchar support

arch: cleanup the 32- and 64-bit selection

arch/ia64: update to the new 64-bit infrastructure

arch/s390: commonalise the 32- and 64-bit s390 arch

arch/x86: commonalise the 32- and 64-bit x86 arch

arch/ppc: commonalise the 32- and 64-bit PowerPC arch

arch: add hidden config knobs for 32- and 64-bit support and select

Add new hidden config knobs that architectures can select to
say whether they support 32- or 64-bit variants, and which
they default to.

Merge.

arch/s390: cleanups

Don't select unneeded config knobs. Don't select non-existing config knobs.
Use the "no patch" config knob, instead of pointing to an non-exiting local
patch dir. Simplify the tuple-related scripts. Update the samples.

config/global: enable not using patches at all

It can be needed to build a toolchain with no patch at all.

arch: add s390 and s390x architectures and samples

Merge.

libc/glibc: allow more than one line in configparms

samples: update the armeb-unknown-linux-gnueabi sample to use glibc-2.10.1

libc/glibc: add 2.10.1

Woo... It seems the glibc guys finally decided that tarballs
were not deprecated, in fact.

The patchset was vampirised from Gentoo (kudos, guys!), and
applies to glibc+ports, so that's why it's been added as a
patchset against ports, not against glibc.

scripts: add a new helper script to easily rediff a patchset

scripts: be POSIXly correct in helper scripts

Fix helper scripts to be POSIXly correct: don't expect '.' (the dot
builtin) to search CWD if it is not in $PATH.

scripts: output renumbered patches in a new directory

When renumbering patches, the original patches get removed and replaced
with the new ones. This can be annoying to loose the original patches.
Fix this by putting the new patchs in a directory of their own.

patches/binutils/2.20: make patches appliable

Fix filenames in patch files for binutils-2.20.
Some patch files were only usable with patch argument '-p0'.
Fix the diff context to match 2.20 release.

Signed-off-by: Frederic Roussel <fr.frasc@gmail.com>