kernel/linux: add latest versions

kernel/linux: fix versions

scripts: check for, and warn about an unset CT_PREFIX_DIR

The user shall provide a directory to install the toolchain into.
If he/she does not, this is an error, and shall be detected properly,
rather than relying on failure down the road.

Thanks to "Pedro I. Sanchez" <psanchez@colcan.ca> for pointing out
the issue:
http://sourceware.org/ml/crossgcc/2009-12/msg00011.html

scripts: correctly warn when the local tarballs directory does not exist

Warn about a missing local tarball directory, only if it was configured.
Avoid the spurious message:
Directory '${CT_LOCAL_TARBALLS_DIR}' does not exist.
Will not save downloaded tarballs to local storage.

Thanks to "Pedro I. Sanchez" <psanchez@colcan.ca> for pointing out the
issue:
http://sourceware.org/ml/crossgcc/2009-12/msg00011.html

configure: install in a sub-dir of --libdir and --docdir

In case the user specifies the LIBDIR with --libdir , or DOCDIR with
--docdir, install our support files in a sub-dir, so as not to mangle
existing (potentially system) files/dirs.
(transplanted from 991fc21dd3cfda7d6448388b3224821f6937f15e)

configure: install in a sub-dir of --libdir and --docdir

In case the user specifies the LIBDIR with --libdir , or DOCDIR with
--docdir, install our support files in a sub-dir, so as not to mangle
existing (potentially system) files/dirs.

scripts: directly spit-out the date in the WiKi table, misc eye-candy

No need to go through a post-processing just for displaying the date...

scripts: fix Host/Target colums in WiKi table

Generate a better-looking WiKi table by re-arranging
the host and target columns.

scripts: fix WiKi table generation

The number of column in the top-most header was not updated to reflect the
fact that a new column was added to show the host (for canadian crosses).

samples: update the Alpha sample

According to: http://sourceware.org/ml/crossgcc/2009-11/msg00109.html

libc/glibc: update 2.10.1 patchset

According to: http://sourceware.org/ml/crossgcc/2009-11/msg00109.html
update the patchset for correct Alpha build.

patches/glibc: allows glibc2.9 to be compiled with binutils 2.20

the configure script had to be modified to accept as/ld at versions greater
than 2.19
Signed-off-by: Frederic Roussel <fr.frasc@gmail.com>

samples: update the AVR32 sample

scripts: update config.{sub,guess}

1.5: update version string to 1.5.2+hg

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>

scripts: some eye-candy

scripts: update config.{sub,guess}

scripts: fix updating config.{sub,guess}

Merge.

samples: update all samples to the new set of options

No version change is made.

config: mark now old versions as being OBSOLETE

These versions are kept for the upcoming release, but they
will be removed from the next release if they are not used.

config/binutils: add latest version 2.20

Also add patchset vampirised from Gentoo.

debug/strace: add latest version, unmarkprevious EXPERIMENTAL

Also propagate the patchset from 4.5.18 to 4.5.19.

debug/gdb: add latest version 7.0

cc/gcc: add latest 4.4.2 version as EXPERIMENTAL

kernel/linux: add latest versions

binutils: remove duplicate config entries for binutils & elf2flt

scripts: add sed expression to apply when renumbering patches

Some patchsets have superfluous members in their names (eg. the ones coming
from Gentoo), so it can come in handy to pass a sed RE to strip them out of
the final patch name.
Also add a 'fake' mode, where the command will only be printed and not
executed, so we can check beforehand if the rename will be OK.

scripts: fis addToolVersion wrt binutils

binutils' config file has moved; update the addToolVerion script accordingly.

kernel/linux: remove the version prompt