Print the time at which at step was finished (along with the time it took to complete).
/trunk/scripts/functions | 7 5 2 0 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
It is similar to CT_DoLog, but instead of printing its arguments, it uses them as a command, and logs the output of that command.
/trunk/scripts/functions | 8 8 0 0 ++++++++
1 file changed, 8 insertions(+)
It seems to be helping gcc somewhat into telling the correct endianness to ld that sticks with little endian even when the target is big (eg armeb-unknown-linux-uclibcgnueabi).
There's still work to do, especially finish the gcc part that is not in this commit.
/trunk/scripts/functions | 9 7 2 0 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
network, most probably due to proxies. Have downloaders (wget and curl)
timeout on too slow connections (they don't by default).
scripts/functions | 17 12 5 0 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
Rationale:
Most of the time, soft-float problems are caused by this sucker of gcc:
it has support for soft float for all of the targets I've tried so far,
but does not activate this code until you dwelve into half a dozen of
files to make it accept to build and link the support code...
So, yes: gcc has soft-float support. And again, yes: gcc is a sucker.
If you select to debug ct-ng, then you have two new options:
- DEBUG_CT_PAUSE_STEPS : pause between every steps,
- DEBUG_CT_SAVE_STEPS : save state between every steps.
To restart a saved state, just set the RESTART make variable when calling make:
- make RESTART=<step_name>
- pipe size in Linux is only 8*512=4096 bytes
- pipe size is not setable
- when the feeding process spits out data faster than the eating
process can read it, then the feeding process stalls after 4KiB
of data sent to the pipe
- for us, the progress bar would spawn a sub-shell every line,
and the sub-shell would in turn spawn a 'date' command.
Which was sloooww as hell, and would cause some kind of a
starvation: the pipe was full most of the time, and the
feeding process was stalled all this time.
Now, we use internal variables and a little hack based onan offset
to determine the elapsed time. Much faster this way, but still
CPU-intensive.
Add a uClibc-0.9.29 patch directory with one patch (from me!).
Update the armeb-unknown-linux-uclibc sample to uClibc-0.9.29.
Some eyecandy in the gdb build process.
- add a framework to easily add new ones
- add gdb as a first debug facility
- add patches for gdb
After the kernel checked its installed headers, clean up the mess of .checked.* files.
Reorder scripts/crosstool.sh:
- dump the configuration early
- renice early
- get info about build system early, when setting up the environment
- when in cross or native, the host tools are those of the build system, and only in this case
- elapsed time calculations moved to scripts/functions
Remove handling of the color: it's gone once and for all.
Update tools/addToolVersion.sh:
- handle debug facilities
- commonalise some code
- remove dead tools (cygwin, tcc)
Point to my address for bug reports.
- the tarball directory is considered as a local copy, and tarballs are copied to a working area,
- the sources and build directories (CT_SRC_DIR and CT_BUILD_DIR) are now computed, and no longer an option,
- the build dir has been renamed from 'build' to 'targets'.
That should ease preparing a tarball of the resulting target.
- use ports addon even when installing headers,
- use optimisation (-O) when installing headers, to avoid unnecessary warnings (thanks Robert P. J. DAY for pointing this out!),
- lowest kernel version to use is only X.Y.Z, not X.Y.Z.T,
- a bit of preparations for NPTL (RSN I hope),
- fix fixing the linker scripts (changing the backup file is kind of useless and stupid);
Shut uClibc finish step: there really is nothing to do;
Add a patch for glibc-2.3.6 weak aliases handling on some archs (ARM and ALPHA at least);
Did not catch the make errors: fixed the pattern matching in scripts/functions;
Introduce a new log level, ALL:
- send components' build messages there,
- DEBUG log level is destined only for crosstool-NG debug messages,
- migrate sub-actions to use appropriate log levels;
Update the armeb-unknown-linux-gnu sample:
- it builds!
- uses gcc-4.0.4 and glibc-2.3.6,
- updated to latest config options set.
- reorder most of the environment setup,
- geting, extracting and patching are now components' sub-actions,
- save the current config as a sample to be used as a pre-configured target.
You might just say: 'Yeah! crosstool-NG's got its own repo!".
Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup.
That means I'm putting backups in place in the afternoon.
That also means we've lost history... :-(
