When targeting mingw32, gcc expects to find its include files
in "mingw/include" instead of the traditional "usr/include".
[Yann E. MORIN: split the original patch]
sstrip is causing more trouble and grief than tolerable.
It is broken at least on PPC. It does not build on non-ELF
systems (eg. mingw32, MacOS-X...). Plus, it is easy to
install.
Hide it behind OBSOLETE.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It happens from time to time that the server mis-behaves, and breaks the
connection right in the middle of nowhere, for no good reason, leaving us
with a partial file, on which the extract pass would choke.
Remove partial downloads, to fail early.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Even when // downloads are not enabled, aria2 can
fail on some servers (eg. uclibc.org).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Parallel downloads can be a bit harsh on the servers,
and some will fail (eg. uclibc.org) in some cases.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The overview.txt file has evolved into more than just an overview.
Split it into chapters, and include the misc tutorials.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
On some Fedora boxen (at least FC13), it is also required
to link with libm when static ppl is used.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This is the change introduced by revision 734 of MPC repository.
Author: Paul Zimmermann <Paul.Zimmermann@loria.fr>
Revision log: [acos.c] fixed problem with GMP_RNDA (should be MPFR_RNDA, and code was wrong)
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
This version has been released a couple of month ago, but it never reached
crosstool-ng tree. This may be linked to the fact that the current 0.9.30.2,
once patched, has nothing much different from 0.9.30.3, released.
I'm not including any patch with this upgrade, on purpose.
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
To reduce filesizes of the toolchain and even improve build times
of projects to be build with this toolchain it is usefull to strip
the delivered toolchain executables. Since it is not likely that we
will debug the toolchain executables itself we do not need the
debug information inside the executables itself.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
Replace the over-engineered and buggy test in CT_SanitizePath
with a straight forward string pattern match, and also
handle empty PATH elements which are qeuivalent to ".".
Thanks-To: Arnaud Lacombe <lacombar@gmail.com>
Signed-off-by: Johannes Stezenbach <js@sig21.net>
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>
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>
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...
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.
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!
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>
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>
