scripts/addToolVersion.sh: add a function to extract fields from versions

This patch adds a function to extract major, minor, revision, etc. from version
numbers.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

kconfig: remove useless 'default n'

kconfig bools are disabled by default, so specifying 'default n' is useless and
noisy. This patch removes all occurrences of 'default n'.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

libc/glibc: commonalise extraction btw glibc and eglibc

glibc and eglibc have a very similar extraction process, so it
makes sense to commonalise it.

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

libc/glibc: fix {e,}glibc add-ons with short or long names

Fixes the issue with {e,}glibc addons having short and long names (such as
eglibc-ports-2_13 and ports), which caused configure scripts to run
through them twice and thus configuring incorrectly.

For instance, the mips64el-n32-linux-gnu toolchain would be recognized
correctly first, but then the second pass would change it to mips32,
building a mixed MIPS-III N32 and MIPS-I libc.

Signed-off-by: Nicolás Reynolds <fauno@kiwwwi.com.ar>
[yann.morin.1992@anciens.enib.fr: remove spurious trailing spaces]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

configure: add possibility to set arbitrary variable in check_for

If check_for is able to find the required prog/inc/lib, allow it to
set an arbitrary variable to 'y'. This variable is then pushed down
to the kconfig definition.

For example:
has_or_abort prog=foobar kconfig=has_foobar

If foobar is available, it yields a kconfig variable defaulting to y:
config CONFIGURE_has_foobar
bool
default y

If foobar is missing, it yields a kconfig variable defaulting to n:
config CONFIGURE_has_foobar
bool

Thus it is possible to depends on that variabel to show/hide options:
config SOME_FEATURE
bool
prompt "Some feature"
depends on CONFIGURE_has_foobar

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

configure: add has_or_warn

By popular request, add a function to only warn on missing stuff.

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

configure: move error message down to has_or_abort

When has_or_warn will come, we do want to print the error message
only in has_or_abort, so move it down there.

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

debug/gdb: bump Linaro revision to 2011.05-0

This patch bumps the Linaro GDB revision to 2011.05-0.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

cc/gcc: bump Linaro revisions to 2011.05-0

This patch bumps the Linaro GCC revisions to 2011.05-0 when applicable.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

debug/gdb: fix runtime sysroot

This patch sets the runtime sysroot to fix the following GDB warning:
"Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code."

The sysroot can later be changed within gdb with the `set sysroot`
command if necessary.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

scripts: fix broken variable name

This patch fixes a config variable name missing its 'CT_' prefix.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

kconfig: fix forward dependencies

In case a set of options are conditional to two different paths,
the forward dependencies in these options is wrong, but in the
first path.

Fix by Arnaud Lacombe on linux-kbuild ML:
http://www.spinics.net/lists/linux-kbuild/msg04832.html

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

kernel/linux: add latest versions

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

1.11: update version to 1.11.3+hg

Tagging release 1.11.3

1.11: update version to 1.11.3

config: document array-capable variables

Update help entries for thos variables that accept multiple
arguments with spaces (aka. array-capable variables).

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

scripts: munge .config to handle array variables

Transfrom array variables from pure strings (in the kconfig output)
into proper bash arrays declarations, for feeding to the build scripts.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

config: rename variables that are arrays

Make it explicit that a variable is an array bu the name of the variable.
It will be used later when .config gets munged to allow both multiple
arguments and arguments with spaces at the same time to be passed from the
configuration down to the build scripts.

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

scripts: interpret *_EXTRA_CONFIG config variables arrays

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

complibs/ppl: fix 0.11-0.11.2 to compile with --disable-shared

PPL 0.11 (through 0.11.2) had a small bug where it still tried to build
and test its Java interface even when shared libraries are disabled.
Since that's exactly what ct-ng does, it explodes.

This is the patch from the PPL authors (see final link below).

More information can be found in these messages/threads:

Anthony's initial report and analysis with Yann:
http://www.cygwin.com/ml/crossgcc/2011-05/msg00046.html

Ron Flory hit the same problem:
http://www.cygwin.com/ml/crossgcc/2011-05/msg00054.html

Anthony's report to the ppl-devel list:
http://www.cs.unipr.it/pipermail/ppl-devel/2011-May/017450.html

Roberto's reply with a link to the fix in the PPL git repo:
http://www.cs.unipr.it/pipermail/ppl-devel/2011-May/017455.html

Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
(transplanted from 139b85d70b623e51f7585e7c64ecb8c6a6cf4567)

complibs/ppl: build only C and C++ interfaces for PPL

By default, PPL wants to build interfaces for any of a variety of
langauges it finds on the local host (python, java, possibly perl, also
more esoteric languages such as ocaml and prolog).

These extra interfaces can double the compile time for the library. For
single-process builds, I found a savings of more than 40%:

default / j1: 716s total, 143.2s avg, 0.52s stdev
just_c / j1: 406s total, 81.2s avg, 0.33s stdev
just_c_cpp / j1: 413s total, 82.6s avg, 0.22s stdev

And for multi-process builds, it approached 50%:

default / j4: 625s total, 125.0s avg, 0.57s stdev
just_c / j4: 338s total, 67.6s avg, 1.25s stdev
just_c_cpp / j4: 327s total, 65.4s avg, 0.36s stdev

Since the PPL we build within ct-ng is only used by GCC, we only need to
build the C and C++ interfaces.

Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
(transplanted from ec30b191f0e3fe9bc73199f0bcb8d789db17aa92)

complibs/ppl: update GMP location configuration argument for PPL v0.11 and later

'configure' for PPL 0.11 (and later) needs "--with-gmp-prefix" to
provide the location of the GMP toolkit; the previous switches were
"--with-libgmp-prefix" and "--with-libgmpxx-prefix".

The upstream log message is:

commit 08dfb6fea094f8c5a533575a3ea2095edce99a6d
Author: Roberto Bagnara <bagnara@cs.unipr.it>
Date: Sun Jul 12 21:39:46 2009 +0200

New configure option --with-gmp-prefix supersedes the (now removed)
options --with-libgmp-prefix and --with-libgmpxx-prefix.

Link: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=08dfb6fea094f8c5a533575a3ea2095edce99a6d

Since PPL's 'configure' ignores unknown switches, we use all three so we
don't have to conditionalize the ppl.sh build script itself.

Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
(transplanted from 4f0c4fb572e2862c24b28e8d27ce7e9cb9adba65)

complibs/ppl: fix 0.11-0.11.2 to compile with --disable-shared

PPL 0.11 (through 0.11.2) had a small bug where it still tried to build
and test its Java interface even when shared libraries are disabled.
Since that's exactly what ct-ng does, it explodes.

This is the patch from the PPL authors (see final link below).

More information can be found in these messages/threads:

Anthony's initial report and analysis with Yann:
http://www.cygwin.com/ml/crossgcc/2011-05/msg00046.html

Ron Flory hit the same problem:
http://www.cygwin.com/ml/crossgcc/2011-05/msg00054.html

Anthony's report to the ppl-devel list:
http://www.cs.unipr.it/pipermail/ppl-devel/2011-May/017450.html

Roberto's reply with a link to the fix in the PPL git repo:
http://www.cs.unipr.it/pipermail/ppl-devel/2011-May/017455.html

Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>

complibs/ppl: build only C and C++ interfaces for PPL

By default, PPL wants to build interfaces for any of a variety of
langauges it finds on the local host (python, java, possibly perl, also
more esoteric languages such as ocaml and prolog).

These extra interfaces can double the compile time for the library. For
single-process builds, I found a savings of more than 40%:

default / j1: 716s total, 143.2s avg, 0.52s stdev
just_c / j1: 406s total, 81.2s avg, 0.33s stdev
just_c_cpp / j1: 413s total, 82.6s avg, 0.22s stdev

And for multi-process builds, it approached 50%:

default / j4: 625s total, 125.0s avg, 0.57s stdev
just_c / j4: 338s total, 67.6s avg, 1.25s stdev
just_c_cpp / j4: 327s total, 65.4s avg, 0.36s stdev

Since the PPL we build within ct-ng is only used by GCC, we only need to
build the C and C++ interfaces.

Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>

complibs/ppl: remove unnecessary (and confusing) --enable-cxx configure switch.

PPL does not use the "--enable-cxx" configure switch at all; it's
possibly a cut-and-paste leftover from 'gmp.sh'. (PPL is written in C++
natively, so it doesn't make much sense to have to enable C++; GMP, on
the other hand, is written in C with an optional C++ wrapper.)

Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>

complibs/ppl: update GMP location configuration argument for PPL v0.11 and later

'configure' for PPL 0.11 (and later) needs "--with-gmp-prefix" to
provide the location of the GMP toolkit; the previous switches were
"--with-libgmp-prefix" and "--with-libgmpxx-prefix".

The upstream log message is:

commit 08dfb6fea094f8c5a533575a3ea2095edce99a6d
Author: Roberto Bagnara <bagnara@cs.unipr.it>
Date: Sun Jul 12 21:39:46 2009 +0200

New configure option --with-gmp-prefix supersedes the (now removed)
options --with-libgmp-prefix and --with-libgmpxx-prefix.

Link: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=08dfb6fea094f8c5a533575a3ea2095edce99a6d

Since PPL's 'configure' ignores unknown switches, we use all three so we
don't have to conditionalize the ppl.sh build script itself.

Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>

1.11: update version to 1.11.2+hg

Tagging release 1.11.2

1.11: update version to 1.11.2

libc/glibc: source common parts instead of symlinking

Symlinks are a nightmare when one is grepping...

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

kconfig: add the nconf frontend

The nconf frontend is the new hot topic in the kconfig land! :-)

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

libc/glibc: use the multi-inclusion capability of the new kconfig

Now that kconfig can include a file multiple times, link the glibc/eglibc
common stuff to two .in.2 files.

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

kconfig: remove mis-leading messages

Unlinke the Linux kernel, crosstool-NG does not (directly) use make
as a frontend, so remove any occurence of reference to running make
after the configuration.

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

kconfig: fix choice multi-display

In case a choices has different combinations, it can be displayed
more than once.

See the discussion thread on the linux-kbuild ML:
http://www.spinics.net/lists/linux-kbuild/msg04709.html

The fix applied here was proposed by Arnaud LACOMBE.
That fix, or a similar one, will probably be pushed upstream soon.

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

kconfig: don't trim spaces with leading pipe

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

kconfig: do not warn on missing env variable

In crosstool-NG, we use env variables for the backend mode.
So it is perfectly legit that these variables are not set.
So do not warn about it.

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

kconfig: update from linux-next

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

config: add main menu title

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

kernel/linux: reorder stuff

Yet another reordering...

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

config: add generated help entries only if present

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

config: fix recursive deps

The latest kconfig stuff is more stringent when it comes to validating
the dependency of the symbols. It is no longer possible to have a symbol
depend on itself (such as our construct for arch/cc/libc/... was doing).

Fix our generated-file infrastructure to avoid these situations when the
new kconfig stuff will be merged (in a following changeset).

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

scripts/addToolVersion: fix gcc complibs dependency

Since the gcc configuration changes, the way to select the
dependent companion libraries has changed.

Update the addToolVersion script to match.

Reported-by: Xun Li <lxfind@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 4cd9cda2265c0c76df3d4ff77a2f3461aae3bc9f)

cc/gcc: fix complibs dependency

Since the gcc configuration changes, the way to select the
dependent companion libraries has changed. The addToolVersion
script was not updated to match, and a new gcc version was
added with this script.

Fix the gcc version; the script will be updated in a subsequent
changeset.

Reported-by: Xun Li <lxfind@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 79947df7ec4b482297ba90c3fe77314336d200e5)

scripts/addToolVersion: fix gcc complibs dependency

Since the gcc configuration changes, the way to select the
dependent companion libraries has changed.

Update the addToolVersion script to match.

Reported-by: Xun Li <lxfind@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

cc/gcc: fix complibs dependency

Since the gcc configuration changes, the way to select the
dependent companion libraries has changed. The addToolVersion
script was not updated to match, and a new gcc version was
added with this script.

Fix the gcc version; the script will be updated in a subsequent
changeset.

Reported-by: Xun Li <lxfind@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

sample: add new Alpha sample with glibc-.13

Sample provided by Ioannis E. VENETIS

Reported-by: "Ioannis E. Venetis" <venetis@mail.capsl.udel.edu>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

libc/glibc: add 2.13

Patchset provided by "Ioannis E. Venetis" <venetis@mail.capsl.udel.edu>
http://sourceware.org/ml/crossgcc/2011-04/msg00072.html
http://sourceware.org/ml/crossgcc/2011-04/msg00073.html

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

libc/glibc: update patchset, add ports patchset

Patchset provided by "Ioannis E. Venetis" <venetis@mail.capsl.udel.edu>
http://sourceware.org/ml/crossgcc/2011-04/msg00072.html
http://sourceware.org/ml/crossgcc/2011-04/msg00073.html

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

complibs/mpfr: add latest version

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

complibs/cloog: add latest version

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

1.11: update version to 1.11.1+hg

Tagging release 1.11.1

1.11: update version to 1.11.1

internals: fix stripping yet once again

Fix typo introduced by changeset #055e505f28be.
Also, handle older versions of gcc (typically, all versions
prior to 4.0.0).

Maxime provided a similar patch, missing the case for the
legacy versions of gcc.

Reported-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 539a3fa894f00888b02c7f89a2046f02c9d51e75)

internals: fix stripping yet once again

Fix typo introduced by changeset #055e505f28be.
Also, handle older versions of gcc (typically, all versions
prior to 4.0.0).

Maxime provided a similar patch, missing the case for the
legacy versions of gcc.

Reported-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

1.11: update version to 1.11.0+hg

Tagging release 1.11.0

1.11: create maintenance branch, update version to 1.11.0

samples: update

Release is coming soon... Time to update samples...

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

internals: fix stripping canadians

We can't run the newly built gcc when it is a canadian cross.
Thus, we can't get the version number, and thus we can't get
the directory libexec subdirectory to strip.

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

scripts: fix installation

Changeset e013ddebc063 forgot to install the samples.mk file.

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

docs: uninstall the man page

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

scripts: fix installing samples

It's been a while now that the working directory CT_WORK_DIR has
been changed from 'targets' to '.build'. Fix the install procedure
to properly tweak the installed samples.

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

debug/gdb: fix Linaro version string

Last update missed updating the version string.

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

kernel/linux: add latest versions

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

config: small help fix up for work dir default

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

debug/gdb: add latest Linaro version

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

debug/gdb: hide Linaro options by default

It can be quite confusing for a new-comer to find strange
version numbers for gdb, so hide the Linaro versions by
default.

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

cc/gcc: add latest Linaro versions

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

cc/gcc: suffle options around

Move options around so it feels more organised.
Add comments to separate groups of related options.

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

config: reorder the kernels sub-menu

Re-organise the sub-menu so that:
- the kernels list comes first,
- followed by kernels generic options
- followed by kernels specific options

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

config: reorder the architectures sub-menu

Re-organise the sub-menu so that:
- the archs list comes first,
- followed by archs generic options
- followed by archs specific options

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

scripts/addToolsVersion: versions can be either in the .in or the .in.2

The components have their version selection handled either in the .in
file or the .in.2 file. Handle both cases.

Also, when dumping an existing version, keep the user's grep options
(ie. do override neither options nor colors).

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

samples: add a new sample for ARM Cortex-A15 with VFP/NEON

Sample origiannly reported and provided by dsreed on the #crostool-ng
channel on freenode. I don't have the real ID for dsreed, but the
sample is not orginally mine, but his/hers.

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

libc/uClibc: use MMU settings

Enforce the MMU settings from the crosstool-NG configuration.

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

scripts: small eye-candy in the wiki table

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

internals/finish: do not remove ${PREFIX}/include

gcc installs the C++ headers in ${PREFIX}/include/ but we trash
that directory at the end of the build.

We previously removed that directory as it contained the companion
libraries header files. But it's been some time now that we isntall
the companion libraries in their own dedicated place, so we do not
need to remove that directory.

Until we have a better fix, just keep that directory for now.

Reported-by: Bob Rossi <bob@brasko.net>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

config/toolchain: hide sysroot name when in backend mode

In backend mode, setting the sysroot name is the
responsibility of the upper-layer build system.

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

cc/gcc: add latest version

Propagate the gcc-4.4.5 patchset to the newly added gcc-4.4.6.

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

kernel/linux: add latest versions

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

scripts: update config.sub

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

scripts/mk-patch: squash all non alphanumeric chars

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

1.10: update version to 1.10.1+hg

Tagging release 1.10.1

1.10: update version to 1.10.1

functions: fix date calculations

In case date(1) does not support nanosecond resolution, it does
not interpret '%N', and leave it as-is. So we have to remove it.

Note that some versions replaces '%N' with 'N', so we have to
take this into account as well.

Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from bb6e2df2427f3db871721c96ca3226cfa24204bc)

functions: avoid CR when progress bar is not enabled

Using CT-NG with progress bar disabled, still prints CR ('\r') characters
on the output. When you capture the output to a file as part of an
automated build, it shows extra empty lines.

For example:

------------------------------------------------------------
[INFO ] Performing some trivial sanity checks

[INFO ] Build started 20110404.113619

[INFO ] Building environment variables

[EXTRA] Preparing working directories

[EXTRA] Installing user-supplied crosstool-NG configuration
------------------------------------------------------------

Signed-off-by: Javier Viguera <javier.viguera@digi.com>
(transplanted from cbd07f3dd6e3689a6b971e999aa82d09fb94d515)

binutils/binutils: hide gold option if no support for current architecture

The gold linker does currently support only a limited set of architectures:
- x86 (32- and 64-bit)
- ARM

Hide the gold option for other architectures.

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

cc/gcc: fix building core when building statically

There was a mishap when cut-n-pasting code from the final
step into the core step: a variable was not renamed.

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

scripts/internals: fix stripping once more

Some scripts have 'very long lines', so the output of 'file'
will have that mentioned, such as:
POSIX shell script, ASCII text executable, with very long lines

Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 21025504dbc91d53eced23e337a547d5c1b94686)

scripts: fix stripping in finalisation step

The heuristic to find shell script is deficient. Fix it.

Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from ade5d48d98f27ba75e28c2f559f1eec9e76e9c59)

libc/glibc: LinuxThreads are no longer supported in latest versions

In fact, it is only supported in a few legacy versions.

Keep LT available for all eglibc versions, although it might need
a similar safeguard...

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

cc/gcc: do not build plugins for static toolchains

Plugins are shared objects, and when building a toolchain statically,
the gcc build system breaks havok (although there is no hard technical
reasons it should not be possible)...

And consequently, do not enable plugin supoprt in binutils.

Reported-by: Thomas Spurden <thomas@ado.is-a-geek.net>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 9139319423fd7d71017dfc974d3a06ab79e08fb8)

internals: don't remove lib64 symlinks in sysroot

The lib64 symlinks are needed for the linker to find the libraries.

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

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>
(transplanted from 2ed26c6465689c024044f79c19ba302f749d0100)

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>
(transplanted from a3818c3b03e053adb8f6b7e6cf326f16a7f0c4aa)

functions: pretty print error messages

Reformat the error messages:
- strip ${CT_LIB_DIR} from scripts path names
- strip ${CT_TOP_DIR} from build.log path and docs path
- overall shorter lines
- point to the known-issues file

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

docs: add a status for know issues

As time passes, a known issues can be no longer applicable (because
the component has been fixed, or a workaround ahs been added in the
crosstool-NG scripts/config...).

Some may also be unconfirmed, with no way to easily trigger the error,
or applies to old versions of components...

Add a status for every known issues.

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

docs: use the error message in the known issues titles

This helps users find the appropriate known issue entry.

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

docs: add known issues summary in the ToC

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

docs: add known issue about missing forced unwind support

This has been reported many times, and has become a FAQ.

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

functions: fix date calculations

In case date(1) does not support nanosecond resolution, it does
not interpret '%N', and leave it as-is. So we have to remove it.

Note that some versions replaces '%N' with 'N', so we have to
take this into account as well.

Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

functions: avoid CR when progress bar is not enabled

Using CT-NG with progress bar disabled, still prints CR ('\r') characters
on the output. When you capture the output to a file as part of an
automated build, it shows extra empty lines.

For example:

------------------------------------------------------------
[INFO ] Performing some trivial sanity checks

[INFO ] Build started 20110404.113619

[INFO ] Building environment variables

[EXTRA] Preparing working directories

[EXTRA] Installing user-supplied crosstool-NG configuration
------------------------------------------------------------

Signed-off-by: Javier Viguera <javier.viguera@digi.com>

complibs: disable building shared libs

Managing the shared version of the companion libraries
has become cumbersome.

Also, it will one day be possible to use the companion
libraries from the host distribution, and then we will
be able to easily use either shared or static libs.

As a side note, while working on the canadian-rework
series, it has become quite more complex to properly
handle shared companion libraries, as they need to be
built both for the build and gost systems. That's not
easy to handle. At all.

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

libc/glibc: remove duplicate patch

Remove a now obsolete patch for glibc-2.9 (a better one has
just been contributed by Esben).

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

libc/glibc: workaround for autoconf'ed define of caddr_t

When building canadian cross compiler, I have some trouble with
configure defining caddr_t as a macro, like:
#define caddr_t char *

When combined with the types.h where caddr_t is protected together
with daddr_t, the typedef of caddr_t breaks.

This patch works around it by protecting the caddr_t typedef
specifically.

I am uncertain as to the real cause and solution to this :-(

Signed-off-by: Esben Haabendal <eha@dev.doredevelopment.dk>

libc/glibc: fix cross-compiling to i686

In OE-lite we use the attached patch for building i686 cross compilers.
Thanks to Khem Raj for original patch :-)

At the same time, remove the corresponding patch that was in
the ports patchset.

CC: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Esben Haabendal <eha@dev.doredevelopment.dk>
[yann.morin.1998@anciens.enib.fr: remove patch from ports]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

libc/glibc-common: force use of the BFD linker

gold can not build glibc/eglibc, force use of the BFD
linker during the toolchain build.

Reported-by: Bill Pringlemeir <bpringle@sympatico.ca>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

binutils/binutils: add blind option to force use of ld.bfd during build

gold is not capable of building glibc/eglibc, so we have to
force using the BFD linker, ld.bfd.

Offer a blind option that affected components can select to
force use of the BFD linker during the build.

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

binutils/binutils: also install the wrapper for the internall ld

ld is also installed in PREFIX/TUPLE/bin, so we need to wrap that
as well.

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

binutils/binutils: warn if only gold is selected

gold is not capable of building glibc/eglibc. See this thread:
http://sourceware.org/ml/crossgcc/2011-04/msg00010.html

Reported-by: Bill Pringlemeir <bpringle@sympatico.ca>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

binutils/binutils: always set name of the default linker

Always export the name of the default linker, even if only
one of them is selected.

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

binutils/binutils: hide gold option if no support for current architecture

The gold linker does currently support only a limited set of architectures:
- x86 (32- and 64-bit)
- ARM

Hide the gold option for other architectures.

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

arch/sparc: add absic support

Add support for building SPARC targeted toolchain.
With this patch I have built a working sparc V8 (32 toolchain).

Testing shows that not all gcc versions works well:
4.4.1 OK (kernel builds and the final kernel can boot)
4.4.2 Not tested
4.4.3 Not tested
4.4.4 BAD (Kernel can build but fails during boot)
4.4.5 BAD (Kernel can build but fails during boot)
4.5.1 BAD (Build fails with a spill related ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664)
4.5.2 OK (kernel builds and boots)

I have successfully been using the 4.5.2 version for a few months.

This patch does not add support for the LEON variant.
That may come later.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[yann.morin.1998@anciens.enib.fr: for 32-bit, default CT_TARGET_ARCH is OK]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

kernel/linux: update to latest versions

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

samples: add first sample to build with gcc-4.6.0

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

cc/gcc: fix linking with static PPL 0.11+

PPL 0.11+ installs three libs: lippl, libppl_c and libpwl.
libppl_c has a dependency on libpwl (at least for watchdog stuff).

While gcc correctly links with libppl and libppl_c, it does not
pull libpwl in. In case of shared libs, this is not a problem, as
libppl_c has a NEEDED dependency on libpwl. But for static libs,
that does not work. Although libppl_c.la exists and has a correct
dependency on lipwl, somehow gcc misses it. So we have to force
pulling libpwl when needed.

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

cc/gcc: hide Linaro options by default

It can be quite confusing for a new-comer to find strange
version numbers for gcc, so hide the Linaro versions by
default.

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

cc/gcc: add linaro 4.6 pre-release

Before gcc 4.6 was released, Linaro has a pre-release available.
Include that version in the config list.

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

cc/gcc: add 4.6.0

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

complibs/ppl: build watchdog library

gcc-4.6+ requires the Parma Watchdog Library (libpwl).
Build it and use it.

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

cc/gcc: prepare for upcoming 4.6

gcc 4.6 will no longer depend on libelf.

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

cc/gcc: cleanup the _or_later logic

So far, we've had a version always select appropriate _or_later option,
which in turn would select all previous _or_later options.

Because the dependencies on companion libs were cumulative, that was
working OK. But the upcoming 4.6 will no longer depend on libelf, so
we can't keep the cumulative scheme we've been using so far.

Have each release family select the corresponding dependencies, instead
of relying on selecting previous _or_later.

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

cc/gcc: update linaro versions

Linaro has released version linaro-4.5-2011.03-0.

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

cc/gcc: fix building core when building statically

There was a mishap when cut-n-pasting code from the final
step into the core step: a variable was not renamed.

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

kernel/linux: update version

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

kernel/linux: add altest version

Fix an incorrect version at the same time... :-(

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

scripts/internals: fix stripping once more

Some scripts have 'very long lines', so the output of 'file'
will have that mentioned, such as:
POSIX shell script, ASCII text executable, with very long lines

Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

kernel/linux: add latest version

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

cc/gcc: log even more

Also log variable assignement for single commands.

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

libc/mingw: log even more

Also log variable assignement for single commands.

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

libc/glibc-common: log even more

Also log variable assignement for single commands.

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

libc/newlib: log even more

Also log variable assignement for single commands.

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

complibs/libelf: log even more

Also log variable assignement for single commands.

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

complibs/mpc: log even more

Also log variable assignement for single commands.

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

complibs/cloog: log even more

Also log variable assignement for single commands.

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

complibs/ppl: log even more

Also log variable assignement for single commands.

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

complibs/mpfr: log even more

Also log variable assignement for single commands.

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

complibs/gmp: log even more

Also log variable assignement for single commands.

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

debug/trace: log even more

Also log variable assignement for single commands.

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

debug/gdb: log even more

Also log variable assignement for single commands.

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

debug/dmalloc: log even more

Also log variable assignement for single commands.

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

binutils/elf2flt: log even more

Also log variable assignement for single commands.

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

binutils/binutils: log even more

Also log variable assignement for single commands.

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

scripts: allow logging of commands with variables

In a lot of places, we need to call some commands with specific
variable settings, a-la:
var1=val1 var2=val2 /foo/bar/buz opt1 opt2

Unfortunately, we currently can not log the variable settings.

Enhance CT_DoExecLog with a crude heuristic that works pretty well
and that can also log setting variables.

Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

scripts: leave changelog in build dir, copy to install dir

Users tend to look for the build log in the current working directory,
rather than in the toolchain's installation dir. While bundling the build
log in the toolchain installation dir is nice for distribution and review,
it can be easier to have the build log readily available in the working
directory, as it is quicker to get to it.

So, the build log stays in the working directory until the toolchain is
completely and successfully built, and then a (compressed) copy is made.

Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

complibs/ppl: add latest version

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

kernel/linux: add newer versions

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

scripts: fix stripping in finalisation step

The heuristic to find shell script is deficient. Fix it.

Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

samples: new PPC e300c3 sample

Gustavo wrote:

---8<---
Attached my ct-ng e300c3 toolchain config for:

powerpc-e300c3-linux-gnu [l X]
OS : linux-2.6.36.3
Companion libs : gmp-5.0.1 mpfr-3.0.0 ppl-0.10.2 cloog-ppl-0.15.10 mpc-0.8.2 libelf-0.8.13
binutils : binutils-2.21
C compiler : gcc-4.5.2 (C,C++)
C library : eglibc-2_12
Tools :
---8<---

Reported-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
["Yann E. MORIN" : updated to match new config options]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

scripts: update config.{guess,sub}

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

binutils/binutils: use log level CFG for ./configure

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

complibs/libelf: use log level CFG for ./configure

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

scripts: do not chmod u+w the whole source directory

Doing a chmod on the whole source dir after every packages
are extracted can take a hell of a lot of time.

The offending packages are far from legion, and they now
have their own chmod u+w to cleanup their own mess...

Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

comptools/libtool: chmod files to u+w

The libtool-2.2.6b tarball contains RO files.
We have to chmod them u+w.

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

comptools/autoconf: chmod files to u+w

The autoconf-2.65 tarball contains RO files.
We have to chmod them u+w.

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

comptools/make: chmod files to u+w

The make-3.81 tarball contains RO files.
We have to chmod them u+w.

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

comptools/automake: chmod files to u+w

The automake-1.11.1 tarball contains RO files.
We have to chmod them u+w.

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

debug/gdb: chmod ncurses files to u+w

The ncurses-5.7 tarball contains only RO files.
We have to chmod them u+w.

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

kernel/linux: add latest 2.6.37.2 version

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

binutils/sstrip: build statically for static toolchains

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

binutils/elf2flt: remove trailing spaces

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

docs: rename chapter 9

Rename the file so that it is the same name as the chapter.

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

docs: add chapter 9 to ToC

Missed in the previous commit... :-/

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

docs: add an in-depth explanations of the build steps

The build process is quite complex: gcc is built three times, there are
two C library steps, there are those companion libraries...

People often wonder what all these steps do, and why they are needed.

Recently, someone proposed a tutorial on the crossgcc mailing list:
http://sourceware.org/ml/crossgcc/2011-01/msg00059.html

This meant that there was a need for such a tutorial, and explanations
on how a toolchain is built. So i decide to extend my answers:
http://sourceware.org/ml/crossgcc/2011-01/msg00060.html
http://sourceware.org/ml/crossgcc/2011-01/msg00125.html

into proper documentation in crosstool-NG.

Thanks go to Francesco for suggesting this. He has a fine tutorial
for beginners there:
http://fturco.org/wiki/doku.php?id=debian:cross-compiler

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

complibs/mpc: add latest version 0.9

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

complibs/ppl: add latest version 0.11.1

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

kernel/linux: fix typo in version string

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

cc/gcc: do not build plugins for static toolchains

Plugins are shared objects, and when building a toolchain statically,
the gcc build system breaks havok (although there is no hard technical
reasons it should not be possible)...

And consequently, do not enable plugin supoprt in binutils.

Reported-by: Thomas Spurden <thomas@ado.is-a-geek.net>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

libc/glibc: LinuxThreads are no longer supported in latest versions

In fact, it is only supported in a few legacy versions.

Keep LT available for all eglibc versions, although it might need
a similar safeguard...

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

libc/glibc: fix dubious construct when installing headers

This is dubious because if the copy fails, then we'll miss the error.

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

libc/glibc: only install start files for NPTL

Building the start files requires a shared-capable compiler, which we do
not have when the threading implementation is LinuxThreads.

So, only build the start files when the threading implementations is NPTL.

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

libc/glibc: add fortify option

By default, recent versions of glibc and eglibc will build some
functions that take format strings (eg. printf, syslog...) with
run-time checks against some format string attacks. This is
called a fortified build.

Unfortunately, this fails somehow while building the instrumented
version of syslog, with some kind of circular dependency...

Disable fortified builds by default, and hide the enabling option
behind EXPERIMENTAL for daring users...

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

internals: don't remove lib64 symlinks in sysroot

The lib64 symlinks are needed for the linker to find the libraries.

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

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>

scripts: fix double slash in paths

Computed paths may contain double slashes.
This is not an issue but it is just ugly to look at.

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

config: add an option to name the sysroot directory

Depending on local policies, some users have expressed a need to
have the sysroot be named differently than the hard-coded name.

Add an option for that.
Default to 'sysroot' to match the existing literature.

While at it, replace 'sys-root' with 'sysroot' everywhere we
reference the sysroot.

Reported-by: Alexey Kuznetsov <Alexey.KUZNETSOV@youtransactor.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

libc: remove now unneeded do_libc_headers

do_libc_headers is now a noop, and is no longer used, so remove that step.

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

libc/glibc-eglibc: misc janitorial cleanups.

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

libc/glibc: add glibc specifics to the shared code, and use it

Final step at sharing code between glibc and eglibc.
Fall, wall of shame, fall!... :-)

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

scripts: PARALLELMFLAGS is evil, rename

The reunification of the glibc/eglibc code paths exposed a nasty
bug in the glibc build: use of PARALLELMFLAGS breaks the build.

See the explanations in that bug report against FC6:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=212111

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

libc/glibc: commonalise assembling the list of addons

glibc and eglibc each have two very similar ways of building this list.
This can, and should definitetly, be shared.

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

libc/glibc: commonalise setting of the minimum supported kernel version

It will be possible to use that also with eglibc, so this hunk belongs to
the common code.

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

libc/glibc: use the common start_files procedure

Use the common procedure, shared between glibc and eglibc. This requires
that glibc-specific bits be included in the shared procedure.

But still build the full libc with the glibc-specific procedure. This will
be commonalised in a future commit.

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

libc/eglibc: cleanup common code for sharing with glibc

Some stuff is eglibc-specific, so needs to be conditonal.

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

libc/eglibc: move generic code to a common file

The build procedure for eglibc is generic enough to
be shared between glibc and eglibc. This includes:
- headers install (empty!)
- start files build
- complete libc build
- libc finish (empty!)
- add-ons list

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

libc/mingw: move content of do_libc_headers into do_libc_start_files

It is unnecessary to split C library preparation into two steps, as only
one really makes sense. So, do_libc_headers is bound to be withdrawn
short-term, in favor of do_libc_start_files.

mingw already had all its start files installation in do_libc_headers, and
do_libc_start_files was empty, just migrate the content of the former into
the latter.


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

libc/uClibc: move content of do_libc_headers into do_libc_start_files

It is unnecessary to split C library preparation into two steps, as only
one really makes sense. So, do_libc_headers is bound to be withdrawn
short-term, in favor of do_libc_start_files.

uClibc already had all its start files installation in do_libc_headers, and
do_libc_start_files was empty, just migrate the content of the former into
the latter.

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

libc-glibc: remove 2.3.6

This is an obsolete version which is no longer used by any sample (the only
user, the ia64 sample, has been removed).

It also makes the code path a bit complex, with twists just to accomodate
that version. Removing the version will make those twists go away, and
will ease commonalisation of glibc and eglibc in the future (hopefully!).

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

arch: remove ia64

ia64 is broken in every gcc/glibc combinations I tested (except for the
existing sample that used very old versions).

Nobody complained on the list about not being able to build recent versions.

So the only way forward I can see is to remove the architecture altogether.

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

kernel/linux: simplify the download URL

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

kernel/linux: longterm kernel location changed

The location of the longterm Linux kernels on FTP has changed.
Here is a simple (but not very versatile) fix.

Signed-off-by: "Björn A. Herwig" <herwig@gdsys.de>
[yann.morin.1998@anciens.enib.fr: make it generic/versatile]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

complibs/cloog: regenerate autostuff files

Latest version of CLooG does not have properly generated autoconf files,
so they need to be regenerated before the call to ./configure

Signed-off-by: "Ilya A. Volynets-Evenbakh" <ilya@total-knowlege.com>
[yann.morin.1998@anciens.enib.fr: make it conditional on 0.15.10 only]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 32c7bbfa3f6514a0fbd5a7388d33e664ba62ed89)

complibs/cloog: regenerate autostuff files

Latest version of CLooG does not have properly generated autoconf files,
so they need to be regenerated before the call to ./configure

Signed-off-by: "Ilya A. Volynets-Evenbakh" <ilya@total-knowlege.com>
[yann.morin.1998@anciens.enib.fr: make it conditional on 0.15.10 only]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

1.9: update version to 1.9.2+hg

Tagging release 1.9.2

1.9: update version to 1.9.2

debug/ltrace: fix building for mips

ltrace 0.5.3 currently fails to build for target mips because MY_TARGET
(introduced by patches/ltrace/0.5.3/150-allow-configurable-arch.patch)
is set to 'mips' via CT_ARCH, while the mips specific stuff in ltrace
(0.5.3) is stored under sysdeps/linux-gnu/mipsel:

result: *** No rule to make target `mips/arch.h', needed by `sysdep.h'.
Stop.

The following patch fixes this issue

Signed-off-by: "Horst Kronstorfer" <horst.kronstorfer@aon.at>
[yann.morin.1998@anciens.enib.fr: reformat commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 2115901c7f07181d92ddbd7dd7ebeaa72e4fb176)

cc/gcc: fix building of ecjx

When building ecjx, the compiler for the build system must
be used, not for the compiler for the host system.

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

complibs/libelf: build with -fPIC

libelf is used by gcc to build the lto-plugin used
by binutils' gold to perform LTO.

This requires that files in libelf be compiled with
-fPIC to generate a proper .so.

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

debug/gdb: fix for psim build failure due to -lz in gdb-7.2.

Signed-off-by: "Horst Kronstorfer" <horst.kronstorfer@aon.at>
[yann.morin.1998@anciens.enib.fr: fix space-damage]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 78286fe70b62cee395bc603a5e44ef136c4531e3)

internals: properly remove all docs

Part of the installed doc was not removed (if configured to).

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

debug/ltrace: fix building for mips

ltrace 0.5.3 currently fails to build for target mips because MY_TARGET
(introduced by patches/ltrace/0.5.3/150-allow-configurable-arch.patch)
is set to 'mips' via CT_ARCH, while the mips specific stuff in ltrace
(0.5.3) is stored under sysdeps/linux-gnu/mipsel:

result: *** No rule to make target `mips/arch.h', needed by `sysdep.h'.
Stop.

The following patch fixes this issue

Signed-off-by: "Horst Kronstorfer" <horst.kronstorfer@aon.at>
[yann.morin.1998@anciens.enib.fr: reformat commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

kernel/linux: add latest versions

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

samples: update i686-nptl-linux-gnu

Enable Java and Fortran frontends.

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

cc/gcc: fix building of ecjx

When building ecjx, the compiler for the build system must
be used, not for the compiler for the host system.

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

samples: update i686-nptl-linux-gnu

Notable changes:
- uses binutils 2.21, builds gold, but defaults to ld
- uses gcc 4.5.2, with GRAPHITE and LTO, builds lto-plugin

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

cc/gcc: build lto-plugin if binutils' gold is built

To properly enable LTO with gold, gcc has to install a plugin that gold
uses to handle the LTO information.

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

binutils/binutils: add wrapper to gold and ld

When both gold and ld are installed, add a wrapper that calls
to either gold or ld.

In case the wrapper is installed, we also need to symlink ld.bfd
and ld.gold for the core_cc steps.

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

binutils/binutils: add support for threaded gold

When configured with support for threads, gold can link in
parallel, possibly cooperating with a make jobserver.

Add an option enabling threads.

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