1.7: update version to 1.7.2+hg

Tagging release 1.7.2

1.7: update version to 1.7.2

scripts: remove . from $PATH

Add CT_SanitizePath function which removes entries referring to ., /tmp
and non-existing directories from $PATH, and call it early in the
build script.

If . is in PATH, gcc-4.4.4 build breaks:

[ALL ] checking what assembler to use...
/tmp/build/targets/arm-unknown-linux-uclibcgnueabi/build/gcc-core-static/arm-unknown-linux-uclibcgnueabi/bin/as
...
[ALL ] config.status: creating as

i.e. "as" is supposed to be the arm-unknown-linux-uclibcgnueabi cross assembler,
but config.status creates a local "as" script which is calling the
host assembler.

Signed-off-by: Johannes Stezenbach <js@sig21.net>
[Yann E. MORIN: style fixes + explanations]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 20dd8cef1c8adff0aa3e78ae6d7acfbc45ed5a83)

complibs: fix using static companion libraries

When building a cross-compiler for a target which uses a file extension for
binaries the symbolic link to cc is not created correctly because the lookup
of the gcc binary is done in a incorrect path

Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
(transplanted from 3917f2dafed1bb189e39f50e8506b3141926d7e1)

cc/gcc: add option to compile against static libstdc++, for gcc-4.4 and newer

Idea and know-how taken from CodeSourcery build script.

Normal build:
$ ldd arm-unknown-linux-uclibcgnueabi-gcc
linux-gate.so.1 => (0xb77f3000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb76e8000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb75a1000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb757a000)
/lib/ld-linux.so.2 (0xb77f4000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb755c000)

CC_STATIC_LIBSTDCXX=y:
$ ldd arm-unknown-linux-uclibcgnueabi-gcc
linux-gate.so.1 => (0xb7843000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb76e6000)
/lib/ld-linux.so.2 (0xb7844000)

I made CC_STATIC_LIBSTDCXX default=y since I think
it is always desirable.

Signed-off-by: Johannes Stezenbach <js@sig21.net>

scripts: remove . from $PATH

Add CT_SanitizePath function which removes entries referring to ., /tmp
and non-existing directories from $PATH, and call it early in the
build script.

If . is in PATH, gcc-4.4.4 build breaks:

[ALL ] checking what assembler to use...
/tmp/build/targets/arm-unknown-linux-uclibcgnueabi/build/gcc-core-static/arm-unknown-linux-uclibcgnueabi/bin/as
...
[ALL ] config.status: creating as

i.e. "as" is supposed to be the arm-unknown-linux-uclibcgnueabi cross assembler,
but config.status creates a local "as" script which is calling the
host assembler.

Signed-off-by: Johannes Stezenbach <js@sig21.net>
[Yann E. MORIN: style fixes + explanations]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

cc/gcc: add option to enable/disable libmudflap

For some scenarii, libmudflap is not very usefull
or can break the build. Make in an optioon that
defaults to 'N' to be on the safe side.

For the core gcc-s, there is absolutely no need
to build libmidflap.

Idea from: Bernhard Pfund <bernhard@chapter7.ch>

cc/gcc: make sjlj config option a tristate

A tristate fits better here than a choice.

cc/gcc: move options around

config: allow unconditional usage of tristates

libc-uclibc: move options

libc/uClibc: fix space damage

libc/uClibc: fix using pre-generated locale data

Some time, someone updated the locale Makefile to use
newer pre-generated locales data, but did not upload
those.

So we just force using the existing, ageing archive,
dating back 20030818. Sigh...

libc/uClibc: do not systematically use pre-generated locale data

It seems that using pre-generated locale data can be more problematic
than usefull in some circumstances.

Offer a config knob to enable/disable use of the pregen locale data.
Also, do not extract pregen locales data ourselves, it's broken.

configure: fix --mandir

--mandir points to the base dir of the man pages, so
we have to append our man section below given dir.
(transplanted from a8a4d5c9773893fa6978e5f9e1445d1e8185c24a)

scripts: add a cross-ldd-like

Add a cross-ldd that mimicks a native ldd.

libc/uClibc: do not install cross-ldd

I was unable to make the cross-ldd from uClibc to work, and
it is not possible to build it on non-POSIX system.

Besides, we have a generic script that is in the starting-blocks
to replace it, that will work for any C library, and also will
work on non-POSIX systems. Bonus!

docs/known-issues: document the "error compiling FC test program" issue

complibs: fix using static companion libraries

When building a cross-compiler for a target which uses a file extension for
binaries the symbolic link to cc is not created correctly because the lookup
of the gcc binary is done in a incorrect path

Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>

libc/uClibc: fix verbosity level for uClibc >= 0.9.30

uClibc >= 0.9.30 supports three verbosity levels, according to "make help":

V="" - Quiet build (default)
V=1 - Brief build (show defines, ld flags)
V=2 - Very verbose build

I think older versions of uClibc treat V=2 the same as V=1.
For current uClibc, only V=2 shows the full command lines.

Signed-off-by: Johannes Stezenbach <js@sig21.net>

scripts/functions: recognise Cygwin build hosts

scripts: use 'hg archive' to create release tarballs

kernel/mingw32: mark as being EXPERIMENTAL

configure: fix --mandir

--mandir points to the base dir of the man pages, so
we have to append our man section below given dir.

scripts: update config.{guess,sub}

Merge.

complibs/ppl: backout #9f0de857cb05

The patch breaks the build on most machines,
while the purpose of the patch is dubious.
So, simply back it out.

debug/gdb: properly remove build tic

tic is isntalled in buildtools, not in the toolchain's bin dir.
Plus, it may have an extension...

debug/gdb: Fix compilation for Mingw hosts

GDB requires PDcurses instead of ncurses while running on Windows.
So, do not always compile ncurses in case GDB needs to build.

PDcurses is provided by an earlier build step and is not described in
this file.

Signed-off-by: Remy Bohmer <linux@bohmer.net>
[yann.morin.1998@anciense.nib.fr: we already have a way to detect ncurses usage]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

complibs/ppl: fix build for MINGW

Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
---
patches/ppl/0.10.2/100-update-for-mingw-build.patch | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 patches/ppl/0.10.2/100-update-for-mingw-build.patch

samples: add Linux -> Mingw32 sample

Sample to build compiler targetting mingw32 target systems

Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
---
samples/i686-pc-mingw32/crosstool.config | 302 +++++++++++++++++++++++++++++++
samples/i686-pc-mingw32/reported.by | 3
2 files changed, 305 insertions(+)
create mode 100644 samples/i686-pc-mingw32/crosstool.config
create mode 100644 samples/i686-pc-mingw32/reported.by

kernel/mingw: add target libraries

Add several development libraries to the build of the mingw cross-compiler
to be used on target

Libraries:
PDCurses (port of the ncurses library)
GnuRX (the regex library)
DirectX
OpenGL

Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: don't show DX and RX versions if disabled]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

kernel: add mingw

Add the option to build a cross-compiler for kernel type 'mingw'.
The resulting cross-compiler can be used to build applications on a Linux host
that can be run on a Windows target.

Compiler is build using the mingwrt and w32-api packages aviable from the
MinGW project (http://sourceforge.net/projects/mingw).

The windows headers (w32-api package) are extracting with the kernel_headers
step The libraries and other headers from both packages are build and
installed in the various steps of libc

Signed-off-by: Bart vdr Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: fix kernel headers comment, don't "return 0"]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

libc: add global threads support option

samples: add an ARMeb uClibc/NPTL experimental sample

cc/gcc: gcc-4.4 does not use MPC

As reported by Johannes Stezenbach, see thread at:
http://sourceware.org/ml/crossgcc/2010-07/msg00017.html

config: no need to push the download mirror in a sub menu

binutils/binutils: add binutils-2.20.1

Signed-off-by: Johannes Stezenbach <js@sig21.net>

kernel/linux: update linux stable releases

Signed-off-by: Johannes Stezenbach <js@sig21.net>

libc/uClibc: fix snapshots

Snapshots are in a subdir named uClibc, not uClibc-snapshot
(or uClibc-YYYYMMDD either).
(transplanted from b13d0db6fa95795bb663bf674372b58221682dd6)

libc/uClibc: enable NPTL for snapshots

Recently, NPTL has matured a lot in uClibc, and more and more
people are interested to at least give it a try. So enable it.

libc/uClibc: fix snapshots

Snapshots are in a subdir named uClibc, not uClibc-snapshot
(or uClibc-YYYYMMDD either).

libc/uClibc: fix munging .config for LT old/new

debug/ltrace: add latest version

scripts/finish: do not try to symlink if sed expr is a no-op

If the sed expression does not transform the
tuple, do not try to create the symlink.
(transplanted from 5d6d3c28a658a65551d4eb5de414fd97b575f314)

scripts/finish: do not try to symlink if sed expr is a no-op

If the sed expression does not transform the
tuple, do not try to create the symlink.

debug/gdb: fix incorrect path

Fix discrepancy between the directory we create,
and the directory into which we install tic.

libc/glibc: fix installed scripts

glibc installs some bash-scripts, but uses the path to the buildtool
bash as interpreter (on the shebang line). This is only a symlink to
the real bash, and thus is not available at runtime.

Fix that by assuming that bash on the target *will* be /bin/bash.

1.7: update version to 1.7.1+hg

Tagging release 1.7.1

1.7: update version to 1.7.1

scripts/wrapper: fix wrong test when checking access to the reall tool

In C, the proper syntax for a bit-wise OR is a single '|', not two.

It worked so far because all was well:
- X_OK == 1
- R_OK||X_OK == 1
- the file we searched for had the x-bit set
-> access( file, R_OK||X_OK ) worked
- inicidentally, the file we searched for also had the r-bit set,
but we were not testing that in fact.
(transplanted from eebcaff6626f09af4f69b7b06f1246a06769d0af)

complibs/gmp: 5.0.0 misses 'EXPERIMENTAL' in the prompt
(transplanted from 95b4a458fd60d3e0911750c2b7c1b6cf36285845)

cc/gcc: fix headers copy for core static
(transplanted from 22ce0c19f06a530d72fd65c89d0777d16c0a97ac)

crosstool-NG.sh: suppress failure message from uname -o

On non-GNU systems (BSD/MacOS) there is no uname -o.
Suppress the failure message on these systems in the
call to set CT_SYS_OS (uname -s actually sets this variable).

yann.morin.1998@anciens.enib.fr: remove 'uname -o' altogether.
(transplanted from acae437fddccd7681c93a3b6c999c0796693d625)

scripts: enhance Makefile for installation

Split the multiple directory copies into autonomous rules.
Fix the autocompletion message.

test-suite: correctly install when not --local

scripts/wrapper: fix wrong test when checking access to the reall tool

In C, the proper syntax for a bit-wise OR is a single '|', not two.

It worked so far because all was well:
- X_OK == 1
- R_OK||X_OK == 1
- the file we searched for had the x-bit set
-> access( file, R_OK||X_OK ) worked
- inicidentally, the file we searched for also had the r-bit set,
but we were not testing that in fact.

cc/gcc: add option do disable PCH

In some cases, using Pre-Compiled Headers breaks the build.
Ass an option to disable building the PCH, as suggested by:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974