Add a generic custom location infrastructure (inspired by the one in
kernel/linux) to allow the user to use custom tarballs or directories
for any component.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
[yann.morin.1998@free.fr: move config option, improve help text, fix API doc]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <131c163c69f9cc81d2be.1349931191@localhost.localdomain>
PatchWork-Id: 190784
Message-Id: <0bbaba9190a76ba97f72.1349931192@localhost.localdomain>
PatchWork-Id: 190785
Currently, if downloads are forbidden, the mirror is still tried for.
Change this way:
- if downlaods forbidden, do not try neither upstream locations nor mirror
- add option to only use the mirror, and avoid upstream locations
Signed-off-by: Austin Morton <austinpmorton@gmail.com>
[yann.morin.1998@free.fr: broaden the if USE_MIRRORto enclode mirror location]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
It's easier to have as much as possible stuff in the same place to
ease backup/restore, and make things easier to follow.
Move the host companion libraries install dir as a sub-dir of the
build-tools install dir (but not directly in it, it would break
for canadian or cross-native).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There really is no good reason to install the core compilers in their
own places, one for each pass. We can install them with the other
build tools.
Also, this implies that:
- there are fewer directories to save/restore
- there are fewer symlinks to create for binutils
- the PATH is shorter
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
A lot of places are currently doing:
mkdir -p foo/bar
cd foo/bar
Or even:
mkdir -p foo/bar
pushd foo/bar
[...]
popd
Provide both wrapper to ease doing this.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In the process of converting to autoconf, the kconfig option
were not properly translated.
Fix that.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Dumping the backtrace has been broken since changeset #652e56d6d35a:
scripts: execute each steps in a subshell
We can spawn sub-sub-shells in some cases.
The way the fault handler works is to dump the backtrace, but to avoid
printing it once for every sub-shell (which could get quite confusing),
it simply exits when it detects that it is being run in a sub-shell,
leaving to the top-level shell the work to dump the backtrace.
Because each step is executed in its own sub-shell, the variable arrays
that contain the step name, the source file and line number, are lost
when exiting the per-step sub-shell.
Hence, the backtrace is currently limited to printing only the top-level
main procedure of the shell.
Fix this thus:
- when dumping the bckatraces for the steps & the functions, remember
it was dumped, and only dump it if it was not already dumped
- at the top-level shell, print the hints
Also, rename the top-level step label.
Reported-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some architectures support a mixed hard/soft floating point, where
the compiler emits hardware floating point instructions, but passes
the operands in core (aka integer) registers.
For example, ARM supports this mode (to come in the next changeset).
Add support for softfp cross compilers to the GCC and GLIBC
configuration. Needed for Ubuntu and other distros that are softfp.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When hardfloat is selected, we need to pass that selection down to
./configure and in the CFLAGS.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
With the upcoming softfp support, the case..esac test would become
a bit convoluted if it were to test three different booleans.
Introduce a new blind string config option that defaults to the
selected floating point type used.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Change CT_ExtractGit so that it clones the repository, instead of just
symlinking it. After cloning, any given ref is checked out, or if no
ref is given, the HEAD of the repository is checked out.
This makes CT_Extract behave similar for git repositories as it does
for tarballs, so that it for example can be used for passing glibc-ports
as a git repository.
Signed-off-by: "Esben Haabendal" <esben.haabendal@prevas.dk>
[yann.morin.1998@anciens.enib.fr: fix incomplete var rename]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Virtually all FTP server available on-line support passive FTP.
At least, this is the case for the servers crosstool-NG needs to
connect to.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, we use either wget or curl, whichever is installed.
In case both are installed, both are used. This means that it
takes a while trying all extensions.
Remove use of wget, and use only curl.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some packages are available as LZMA tarballs. LZMA is a relatively recent
compression algorithm; it's slightly better than bzip2, but offers much
faster decompression. LZMA is now deprecated in favor of XZ, but some
packages switched to LZMA when XZ was not yet available, or still in its
infancy. Latest XZ (which totaly obsoletes LZMA) offers a backward LZMA-
compatible utility, so we can check for 'lzma' nonetheless.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
./configure does check for the presence of gz and bzip2, so we can
safely use them in the build scripts.
On the other hand, more recent formats (eg. XZ) are not yet widely
available, and we do not want, and can't, force the user to install
them as a pre-requisite.
So, build up a list of allowed tarball formats based on the available
decompressors. For no, this is a static list, but the upcoming XZ
support will conditionnaly add to this list.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When downloading via svn/cvs/... an attempt to retrieve from the
mirror is made. If the mirror does not have the required tarball,
an error message is printed. This is misleading, as the download
may later succeed via svn/cvs/...
Remove the messages about failed downloads altogether.
At the same time, use "if ... then ... fi" instead of "... && ..."
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This is needed later, when we'll conditionnally use both the
upstream and the mirror URLs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, the mirror can be used either:
- as a fallback in case upstream is unavailable (default behavior)
- as the preferred source for downloads
But the most common use-case seems to provide a truely-LAN mirror
to speed up downloads in big corpos', and/or provide a 'trusted'
source for the tarballs.
So, make the following changes;
- if a mirror is specified, always try that before trying upstream
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The cvs download helper looks for the local tarballs dir to see if it
can find a pre-downloaded tarball, and if it does not find it, does
the actual fetch to upstream via cvs.
In the process, it does not even try to get a tarball from the local
mirror, which can be useful if the mirror has been pre-populated
manually (or with a previously downloaded tree).
Fake a tarball get with the standard tarball-download helper, but
without specifying any upstream URL, which makes the helper directly
try the LAN mirror.
Of course, if no mirror is specified, no URL wil be available, and
the standard cvs retrieval will kick in.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The svn download helper looks for the local tarballs dir to see if it
can find a pre-downloaded tarball, and if it does not find it, does
the actual fetch to upstream via svn.
In the process, it does not even try to get a tarball from the local
mirror, which can be useful if the mirror has been pre-populated
manually (or with a previously downloaded tree).
Fake a tarball get with the standard tarball-download helper, but
without specifying any upstream URL, which makes the helper directly
try the LAN mirror.
Of course, if no mirror is specified, no URL wil be available, and
the standard svn retrieval will kick in.
Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When retrieving tarballs from upstream, if no URL was given, do not
fail; simmply ignore that fact.
This will be used later when the SVN helper will call the standard
helper to try the LAN mirror before trying svn.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some archives like those of the 2011.07 revisions of Linaro GCC contain a folder
name different from the archive basename, which leads to errors afterwards, e.g.
when patching. E.g.:
gcc-linaro-4.5-2011.07.tar.bz2 extracts to gcc-linaro-4.5-2011.07-0/
This patch changes CT_Extract() to force the extraction of all archives to a
folder named like the archive basename. E.g.:
gcc-linaro-4.5-2011.07.tar.bz2 now extracts to gcc-linaro-4.5-2011.07/
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
In case of eglibc, some add-ons that were previously external are
now internal (bundled with the main sources).
So we do not want to fail if an add-on can't be downloaded; we
want to post-pone the check until we can extract the main archive.
So:
- try to retrieve the add-on
- if it fails, print a warning instead of calling CT_Abort
- return 1
So, components that want to catch the error and want to handle it can,
while components that do not will gracefuly fail thanks to our catching
every errors.
Bonus: it works without changing any existing retrieval procedure! :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
For glibc/eglibc, if the add-on can not be extracted, we want to catch
the error to print a meaningful error message.
So:
- try to extract the tarball
- if it fails, print a waring instead of calling CT_Abort
- return 1
So, components that want to catch the error and want to handle it can,
while components that do not will gracefuly fail thanks to our catching
every errors.
Bonus: it works without changing any existing extract procedure! :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In case of glibc/eglibc, some add-ons that were previously external are
now internal (bundled with the main sources).
So we do not want to fail if an add-on tarball can't be downloaded; we
want to post-pone the check until we can extract the main archive.
So:
- try to download the tarball
- if it fails, print a warning instead of calling CT_Abort
- return 1
So, components that want to catch the error and want to handle it can,
while components that do not will gracefuly fail thanks to our catching
every errors.
Bonus: it works without changing any existing retrieval procedure! :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Download to an intermediate temp file, and rename it to its final
name only of download succeeds.
This catches both a failed download, and also the case where the user
interrupts the download. Thus, the a partial download gets discarded,
and we no longer try to extract a partial tarball, which we would
previously have done.
Suggested by Thomas PETAZZONI.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It can happen, in some circumpstances, than one can succeed where
the other would fail. Those cases involves convoluted enterprise
networks with proxies playing tricks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The save/restore state output is voluminous; using this flag allows us
to quickly see or ignore when something is just being saved.
[Yann E. MORIN: this is a blind log level, and is used only to search
in the build-log afterward.]
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
