libtoolize must be checked_for and there needs to be a wrapper
that points to GNU libtoolize since that may be installed
as glibtoolize.
This fixes a problem with building Cloog/PPL that was
Reported-by: "Pierrick Brossin" <pierrick@bs-network.net>
Signed-off-by: "Titus von Boxberg" <titus@v9g.de>
Autostuff tradiotionnally have some switches to set host, build and
target systems, static or shared libs, and a bunch of others...
In the crosstool-NG case, they do not matter, as crosstool-NG is
just a set of scripts (there are C files, but they are compiled
after installation, at runtime, so it does not count).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some upstream now release tarballs compressed with xz, along with the
more traditional bzip2 and/or gzip tarballs. xz (and its predecessor
lzma) achieves better compression, so is a good candidate to shorten
the time it takes to download the source tarballs.
Enable downloading xz-cmopressed tarballs if the user has xz-utils.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
svn is needed to download eglibc from the upstream repository.
In some situations, though, it can happen that:
- the developpers' machines do not have svn
- a LAN mirror has been set-up with pre-downloaded eglibc tarballs
In this case, it makes sense not to hard-depend on svn.
So, if svn is missing, just say so, and add a comment in the
menuconfig.
Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
cvs is used to get newlib directly from its repository. Missing cvs
will only allow getting newlib from the released tarballs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It is useful to sometime run on a strictly POSIX-compliant
shell... :-/
And it is sometime interesting to refresh Q-patches before
finishing the series... :-(
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Rather than building all possible library names in the caller,
lets just do it once in check_for.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Static liunking is not supported on Darwin, so hide the corresponding
options when the build machine is Darwin.
Reported-by: Andrea Franceschini <therealmorpheu5@gmail.com>
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: "Titus von Boxberg" <titus@v9g.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Indent the error/warning message so that it is explicit that
the second line is giving details for the first general hint.
Reported-by: Titus von Boxberg <titus@v9g.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
./configure now has the possibility to check for libraries and headers
in one go, so we can use it! :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Cross-gdb depends on expat and python. If either is missing, cross-gdb will
build successfully, but lacking some features.
Especially, if expat is missing, cross-gdb will be unable to parse the target
description, which may lead to runtime malfunctions and the following GDB
warning:
"Can not parse XML target description; XML support was disabled at compile time"
Hence, expat should be considered mandatory.
On the other hand, the features missing without python are not critical, so
python should not be considered mandatory.
This patch does the following:
- At configure time, warn the user if either expat or python is missing.
- In menuconfig, disable the static build options regarding cross-gdb if no
static version of expat is available, and disable cross-gdb if expat is
missing.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
[yann.morin.1998@anciens.enib.fr: add comment for impossible static cross-gdb]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, check_for() can only test one of prog, inc or lib at once. This patch
removes this limitation.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Currently, error messages just state the obvious: a required
component is required. While in some cases, there is not much
else to say, in some other cases we could tell much more.
For example, a missing libstdc++ means no static toolchain.
Also, format error and warning messages in a similar fashion,
with a {error,warning} intro, followed by the message specified
by the caller.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Hide the staticaly linked libstdc++ option if the static libstdc++ is not
present, detected at configure time.
Add a blind option that says whether static linking is possible at all.
It defaults to 'y', but depends on the needed CONFIGURE_* options. For
now, it only depends on static libtdc++, but new dependencies can be
easily added.
Hide the global static toolchain option behind this new option.
Original patch by Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It's probably a good thing to check for at least one instance of
libstdc++.{so,dylib,a} at configure time. At least one is needed
by the companion libraries and gcc.
Original patch by Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
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>
When configuring in an hg clone, we need hg to compute the version string.
It can happen that users do not have Mercurial (eg. if they got a snapshot
rather that they did a full clone). In this case, we can still run, of
course, so simply fill the version string with a sufficiently explicit
value, that does not require hg. The date is a good candidate.
aria2 is a powerfull downloader that is capable of chunking and
parallel retrieval.
Due to li;itations in crosstool-NG retrieval facilities, it's not possible
to take fully advantage of aria2. It might happen that, in the future,
those limitations get lifted away, so we can take use features such as
parallel downloading from more than one server at the same time. For now,
it should still speed up downloads thanks to parallel downloading of chunks.
In case the user specifies the LIBDIR with --libdir , or DOCDIR with
--docdir, install our support files in a sub-dir, so as not to mangle
existing (potentially system) files/dirs.
Split the has_or_abort function in two:
- one that checks if the tool if found,
- one that calls the above check, and aborts if not found
The rational behind this is to be able to check for a tool
and if not found, fallback to using our bundled version,
should the need arise (and I get time).
For every components where it makes sense, use bash arrays (instead
of a string with space-separated values) to store the options pased
to ./configure.
The configure script fails on automake-1.11 (in Fedora-11) since
it looks for 3-digit version number.
Patch fixed by "Yann E. MORIN", with the added comment:
The check for the automake version is not against a 3-digit number,
but really against a 3-part version number, a-la 'x.y.z'. Versions
such as 1.10 and 1.11 are also valid.
