2011-07-161.11: update version to 1.11.4+hg 1.11
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sat, 16 Jul 2011 01:01:30 +0200] rev 2562
1.11: update version to 1.11.4+hg

2011-07-16Tagging release 1.11.4 1.11
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sat, 16 Jul 2011 01:01:30 +0200] rev 2561
Tagging release 1.11.4

2011-07-161.11: update version to 1.11.4 1.11 crosstool-ng-1.11.4
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sat, 16 Jul 2011 01:01:30 +0200] rev 2560
1.11: update version to 1.11.4

2011-07-14configure: add yet a bit more of autostuff compatibility 1.11
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Thu, 14 Jul 2011 17:59:33 +0200] rev 2559
configure: add yet a bit more of autostuff compatibility

Well, at least it helps buildroot! :-)

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

2011-07-12scripts, cc/gcc: do not fail on existing symlinks or build.log 1.11
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Tue, 12 Jul 2011 23:52:24 +0200] rev 2558
scripts, cc/gcc: do not fail on existing symlinks or build.log

If the user builds a toolchain over an existing one, so, without removing
CT_PREFIX_DIR, the build fails as the symlinks already exist, as does the
build.log.

This can also happen (for build.log) if the user first ran in download-
or extract-only.

Patch (with no SoB) originally from:
Phil Wilshire <phil.wilshire@overturenetworks.com>

Modified by me as it did not apply cleanly.

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

2011-04-15scripts/internals: do not remove lib{32,64}/ symlinks after build 1.11
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Fri, 15 Apr 2011 00:22:42 +0200] rev 2557
scripts/internals: do not remove lib{32,64}/ symlinks after build

During the build, we create lib{32,64}/ symlinks out of the sysroot.
In some cases (eg. mingw32 target), these symlinks are still required
when running the toolchain. For other combinations, the symlinks are
without incidence, so they can be safely kept after the build.

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

2011-07-10scripts: on startup, also remove the buildtools dir 1.11
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Sun, 10 Jul 2011 00:02:05 +0200] rev 2556
scripts: on startup, also remove the buildtools dir

In case there's one lingering around (whether the previous build was
successful, or failed), we have to remove the buildtools directory
as well as the toochain build dir.

This should also fix the case where out makeinfo wrapper calls
itself recursively.

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

2011-04-15cc/gcc: fix passing args with spaces when calling core gcc 1.11
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Fri, 15 Apr 2011 00:05:53 +0200] rev 2555
cc/gcc: fix passing args with spaces when calling core gcc

Spaces in arguments to the core gcc backend were not handled.

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

2011-06-28cc/gcc: remove --enable-symver option 1.11
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> [Tue, 28 Jun 2011 23:46:04 +0200] rev 2554
cc/gcc: remove --enable-symver option

That option is coming from the original crosstool, and is not entirely
understand here.

Moreover, it breaks with newer gcc-s: 4.6.1 now breaks while configuring
libjava (and probably some other libs as well, untested).

There is an related bug report to the gcc BZ:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49555

If need be, the old behavior can be restored with:
CC_CORE_EXTRA_CONFIG_ARRAY="--enable-symver=gnu"
CC_EXTRA_CONFIG_ARRAY="--enable-symver=gnu"

Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from b24ead1a59472195f5b2071ff70664c36fa21c3f)

2011-05-27libc/glibc: fix {e,}glibc add-ons with short or long names 1.11
"Nicolás Reynolds" <fauno@kiwwwi.com.ar> [Fri, 27 May 2011 22:02:30 -0300] rev 2553
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>
(transplanted from af25723a794f2017f45c300369a6d36849e22236)