| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fortran is not supported for all targets, though. ARM at least does not work.
/trunk/scripts/build/binutils.sh | 8 8 0 0 ++++++++
/trunk/scripts/build/cc_gcc.sh | 11 6 5 0 ++++++-----
/trunk/scripts/crosstool.sh | 10 9 1 0 +++++++++-
/trunk/tools/addToolVersion.sh | 3 3 0 0 +++
/trunk/steps.mk | 2 2 0 0 ++
/trunk/config/cc/gcc.in | 16 16 0 0 ++++++++++++++++
6 files changed, 44 insertions(+), 6 deletions(-)
|
|
Move build binutils' target libraries after final gcc.
Have a unique list of steps, it's easier to maintain.
/trunk/scripts/build/binutils.sh | 8 5 3 0 +++++---
/trunk/scripts/crosstool.sh | 16 2 14 0 ++--------------
/trunk/steps.mk | 29 16 13 0 ++++++++++++++++-------------
3 files changed, 23 insertions(+), 30 deletions(-)
|
|
Consider the proxy has to be in a 'local' network. It means it is directly
reachable by the local machine, even if the local machine has to hop through
one or more gates to reach the proxy (often the case in enterprise networks
where class A 10.0.0.0/8 is in fact sub-divided into smaller networks, each
one of them in a different location, eg. 10.1.0.0/16 in a place, while
10.2.0.0/16 would be on the other side of the world). Not being in the same
subnet does not mean the proxy is not available.
So we will build a mask with at most high bits set, which defines a network
that has both the local machine and the proxy. Because a machine may have
more than one interface, build a mask for each of them, removing 127.0.0.1
which is added automagically by tsocks, and removing duplicate masks.
If all of this does not work, then it means the local machine can NOT in fact
reach the proxy, which in turn means the user mis-configured something (most
probably a typo...).
/trunk/scripts/crosstool.sh | 61 52 9 0 +++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 52 insertions(+), 9 deletions(-)
|
|
Implement a much simpler way.
/trunk/scripts/crosstool.sh | 27 5 22 0 +++++----------------------
1 file changed, 5 insertions(+), 22 deletions(-)
|
|
- a machine may well be able to reach the proxy, even if it is not on the same sub-net(s) as the machine itself (absolutely legitimate)
- tsocks.conf needs a list of so-called 'local' networks that can be reached without the need for a SOCKS connection
- SOCKS proxies are expected to be in 'local' networks
- there is absolutely NO way to tell what networks are local, besides the sub-net(s) the machine is in
Therefore, appropriate configuration of SOCKS 4/5 configuration is really complex, and attempts to correctly overcome this issue are doomed.
/trunk/scripts/crosstool.sh | 52 46 6 0 ++++++++++++++++++++++++++++++++++----
/trunk/config/global/download_extract.in | 39 31 8 0 +++++++++++++++++++++++------
2 files changed, 77 insertions(+), 14 deletions(-)
|
|
/trunk/scripts/crosstool.sh | 9 5 4 0 +++++----
/trunk/config/global/download_extract.in | 2 1 1 0 +-
2 files changed, 6 insertions(+), 5 deletions(-)
|
|
As for the HTTP proxy, this is completetly untested, as I have no such proxy at home.
scripts/crosstool.sh | 45 31 14 0 +++++++++++++++++--------
config/global.in | 95 81 14 0 +++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 112 insertions(+), 28 deletions(-)
|
|
scripts/crosstool.sh | 14 14 0 0 +++++++++++++
config/global.in | 54 54 0 0 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 68 insertions(+)
|
|
|
|
with ancient findutils.
|
|
directory does not exist.
|
|
the files.
Removed the locale check as it is now irrelevant.
Removed the experimental binutils 2.17.50.0.xx: 2.18 is here now.
|
|
Big endian is still missing, though...
|
|
|
|
Apply this framework into building of glibc and gcc.
(Whoo! 500th commit! Yeah!)
|
|
|
|
|
|
API is not yet defined.
|
|
|
|
Document overriding the number of // jobs.
Some small documentation fixes.
|
|
|
|
|
|
This option is used as a sed expression to pass onto CT_TARGET to create an alias.
|
|
stop if the main script fails and ends before all directories were removed.
|
|
|
|
|
|
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.
|
|
example). This fixes it.
|
|
|
|
|
|
|
|
|
|
|
|
"foobar was not found in /bin:/usr/bin:...." directly on stderr)
|
|
Homogenise the references to crosstool-NG:
- the project is named "crosstool-NG"
- the front-end is named "ct-ng"
- don't use shortcuts (such as "ct-ng" to stand for "crosstool-NG")
Default action is to print help.
Don't speak of make rules when dumping help, just speak of actions.
|
|
- ./configure --prefix=/some/place
- make
- make install
- export PATH="${PATH}:/some/place/bin"
- ct-ng <action>
|
|
"${CT_PREFIX_DIR}/build.log".
Add an option to compress the log file upon successfull build.
Make rendering the toolchain read-only optional.
A few eye-candy fixes.
|
|
Users of the log facility are in charge to use, move, delete this log file, now.
|
|
build.
|
|
|
|
- cc_core_pass_1 is really cc_core_static,
- cc_core_pass_2 is really cc_core_shared.
|
|
away...).
|
|
|
|
|
|
That still leaves the linuxthreads stuff broken, but it was just before. I don't care anyway. Time to fix that later...
|
|
Update the Makefile help and the documentation accordingly.
|
|
|
|
removed. Log this to DEBUG.
Remove last remnants of color scheme.
Small fixes to some comments.
|
|
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.
|
Yann E. MORIN"