kernel/linux: add latest versions

... and remove old versions.

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

comptools: install them side-to-side with build tools

As companion tools might or might not be used to build each
toolchain, they do belong to that toolchain's build tools,
not to the generic override tools.

Fix a typo in the autoconf URL.

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

buildtools: the buildtools dir is in fact a prefix

Consider the buildtools install directory as a prefix directory,
that is, install buildtools in prefix/bin/, not in prefix/.

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

buildtools: move to working directory

There is absolutely *no* reason for the buildtools (wrappers to gcc, g++,
as, ld... for the local machine) to be in the toolchain directory. Moreover,
they are removed after the build completes.

Move them out of the toolchain directory, and into the build directory (but
yet the part specific to the current toolchain). This means we no longer
need to explicitly remove them either, BTW, but we need to save/restore them
for the restart feature.

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

buildtools: store path to buildtools in a variable

Currently, the buildtools are installed relative to ${CT_PREFIX_DIR}.
Change that by introducing ${CT_BUILDTOOLS_DIR}, which is
still set relative to ${CT_PREFIX_DIR}, but which will make it easy
to change in the future.

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

scripts: create the makeinfo wrapper before we set PATH

If we set PATH to the tools wrappers before we create the
makeinfo wrapper, then we may well wrap an existing wrapper
from a previous run.

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

kernel: move the headers install step

The kernel headers are only needed just before we build
the C library headers, and need not be present before.

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

debug/gdb: add versions from Linaro

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

cc/gcc: add versions from Linaro

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

internals: fix stripping host binaries

The gcc used by linaro has a version number specific to Linaro, but
identifies itself with its upstream version numbering scheme.

This breaks the strip in the finish step, because the actual gcc version
is not the same as the configured one (eg. 4.5.2 vs. linaro-4.5-2011.02-0).

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

libc/eglibc: Make eglibc 2.11 and 2.12 not experimental

I haven't noticed the usual experimental testers complain about eglibc
2.11 or 2.12 being unstable. So stop marking them as experimental.

Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>

libc/eglibc: Add 2.13 branch

Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>

1.10: update version to 1.10.0+hg

Tagging release 1.10.0

1.10: create maintenance branch, update version to 1.10.0

1.9: close branch

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

1.9: update version to 1.9.3+hg

Tagging release 1.9.3

1.9: update version to 1.9.3

libc/mingw: do not remove support symlink

Under mingw, it seems that there is a mix between the traditional /usr
directory, and a similar-purposed /mingw directory (both in the sysroot).

Currently, we create /mingw as a symlink to /usr, and we removed it in
the libc-finish step.

Unfortunately, this prevents the pre-processor to find the headers.
Keeping the symlink makes it magically work...

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from fa5c70b11fecf390c78780fe8f8ba0a836a59e92)

samples: update the samples

Release time is coming at a fast pace. It is now time to
update the samples so they apply cleanly.

The canadian-cross sample mingw32,i686-none-linux-gnu has
been replaced with i586-mingw32msvc,i686-none-linux-gnu.

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

libc/glibc: add option to force unwind

We make it an option, as not all combinations of architectures
vs. compiler vs. glibc/eglibc exhibit the issue. Mostly visible
on old glibc versions, it seems...

This is a missing part from the glibc/eglibc merger... :-/

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

scripts: update tools

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

cc/gcc: enable plugins if needed

Enabling plugins in binutils is not enough, and gcc also
needs to be ./configured with --enable-plugins, although
this is not documented anywhere... :-/

Reported-by: karthik duraisami <kdconstant@hotmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

scripts: squash the multi-slash in the sysroot symlink

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

comptools: add make-3.81

Since the advent of make-3.82, some packages now break due to changes
in make-3.82, being stricter than 3.81 when interpreting the Makefiles.

This has bugged us a bit too much so far, and I believe fixing all
of them is a long road, while simply building make-3.81 is the easiest
route for now.

Of course, in the long term, packages will get fixed upstream, and we
should back-port the fixes to old versions, and get rid of building
make-3.81. In the meantime...

Reported several times on the mailing list.

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

config: add an option not to remove the destination directory

In certain circumstances, removing the destination/installation directory
is a bad idea. For example, when the build environment is already taking
care of sanitising the build tree, and pre-installs stuff in there, it is
a very bad idea to remove the destination directory.

This happens now in buildroot, as the crostool-NG backend now installs the
toolchain in the common host-tools directory, and pre-install there a few
host-utilities (eg. host-automake and host-gawk).

Provide a config knob to turn on/off the removal of the destination
directory, defaulting to 'y' (previous behavior), and forced to 'n' when
used as a backend.

Reported-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

samples: update the mingw sample

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

libc/mingw: do not remove support symlink

Under mingw, it seems that there is a mix between the traditional /usr
directory, and a similar-purposed /mingw directory (both in the sysroot).

Currently, we create /mingw as a symlink to /usr, and we removed it in
the libc-finish step.

Unfortunately, this prevents the pre-processor to find the headers.
Keeping the symlink makes it magically work...

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

config/toolchain: force use of sysroot if OBSOLETE is not set

Use of the sysroot is highly recommended, and the non-sysroot case is
both obsolete and not widely tested.

Before the non-sysroot case can go away, deprecate it.

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