- fix Makefile to really, really not used built-in rules and variables
- have scripts/crosstool-NG.sh generated from scripts/crosstool-NG.sh.in
- create a bin-overide directory ( in ${CT_WORK_DIR}/bin ) that contains shell wrappers to the actual discovered tools
/trunk/scripts/crosstool-NG.sh.in | 27 23 4 0 +++++++++++++++++++++---
/trunk/Makefile.in | 50 48 2 0 +++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 71 insertions(+), 6 deletions(-)
The glibc.sh script doesn't handle the glibc versions with
an underscore very well (bash expected integer error). I
have attached a small patch for that. Instead of looking
for "not period" I changed the sense to look for numbers.
I initially tried to make it look for either a period or
an underscore, but that didn't work like I wanted (probably
because I did something wrong).
Original patch modified to be more robust.
/trunk/scripts/build/libc/glibc.sh | 8 4 4 0 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
... I added a step after
"debug" called "finish", and moved the code in crosstool.sh
after the loop that processes the steps from crosstool.sh
into a do_finish function in functions. Thus, it is now
possible to restart after the "debug" step to re-do the
final few things (clean and compress).
/trunk/scripts/crosstool-NG.sh | 38 0 38 0 --------------------------------------
/trunk/scripts/functions | 42 42 0 0 ++++++++++++++++++++++++++++++++++++++++++
/trunk/steps.mk | 3 2 1 0 ++-
3 files changed, 44 insertions(+), 39 deletions(-)
On 20090115.0012+0100, "Andy Johnson" <ajohnson@aecno.com> wrote:
ltrace wouldn't build on PowerPC because in the
sysdeps/linux-gnu directory in the ltrace source tree
the powerpc directory is called ppc. I added some code
in 400-ltrace.sh to create a symlink for it so it will
build now.
Patch slightly modified by me before applying.
/trunk/scripts/build/debug/400-ltrace.sh | 5 5 0 0 +++++
1 file changed, 5 insertions(+)
After all, this is not crosstool, but really crosstool-NG!
/trunk/steps.mk | 2 1 1 0 +-
/trunk/ct-ng.in | 2 1 1 0 +-
2 files changed, 2 insertions(+), 2 deletions(-)
- don't remove directories in the background:
- it is highly dangerous
- it can lead to data loss in case of frequent stop/restart with a slow disk
- log actions with CT_DoExecLog as much as possible, instead of using |CT_DoLog
/trunk/scripts/crosstool.sh | 100 43 57 0 ++++++++++++++++++++++-----------------------------
1 file changed, 43 insertions(+), 57 deletions(-)
Andy JOHNSON wrote:
The Java compiler for GCC versions 4.3.0 and up requires the
Eclipse compiler "ecj1" to be built as well. I added "gcj" to
the list of utilities to make the initial link.
/trunk/scripts/build/cc/gcc.sh | 12 12 0 0 ++++++++++++
/trunk/scripts/crosstool.sh | 2 1 1 0 +-
/trunk/config/cc/gcc.in | 6 6 0 0 ++++++
3 files changed, 19 insertions(+), 1 deletion(-)
- DUMA separates its name from its version with an underscore, not with a dash.
/trunk/scripts/build/debug/200-duma.sh | 3 2 1 0 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
- renaming the dircetory in CT_ExtratAndPatch is wrong:
- patches against the C library addons may be build against the short *or* long name... :-(
- symlink is more robust, even if less nice
- renaming the directory _after_ CT_ExtractAndPatch is too late:
- if patches are against the short name, and we renamed too the long name, patches don't apply
- so we'll never reach the point where we rename
/trunk/scripts/build/libc/glibc.sh | 1 0 1 0 -
/trunk/scripts/build/libc/eglibc.sh | 1 0 1 0 -
/trunk/scripts/functions | 2 1 1 0 +-
3 files changed, 1 insertion(+), 3 deletions(-)
CT_LIBC_FILE:
- that one was not easy, as it had sneaked into CT_ExtractAndPatch
- which in turn made CT_ExtractAndPatch have references to C library addons
- which in turn relieved the C library _extract functions from doing their own job
- which in turn imposed some nasty tricks in CT_ExtractAndPatch
- which in turn made life easier for the DUMA _get and _extract functions
- which unveiled some bizare behavior for pushd and popd:
- if using smthg ike: 'pushd foo |bar':
- the directory is *neither* changed
- *nor* is it pushed onto the stack
- which made popd fail
CT_MakeAbsolutePath:
- used only to make CT_LOCAL_TARBALLS_DIR canonical
- which is ((almost) useless:
- hopefully, the user entered a full path already
- if it's not the case, too bad...
/trunk/scripts/build/debug/200-duma.sh | 5 1 4 0 +--
/trunk/scripts/build/libc/glibc.sh | 61 32 29 0 +++++++++++++++++---------------
/trunk/scripts/build/libc/uClibc.sh | 16 10 6 0 +++++---
/trunk/scripts/build/libc/eglibc.sh | 48 26 22 0 ++++++++++++++-----------
/trunk/scripts/crosstool.sh | 8 0 8 0 ----
/trunk/scripts/functions | 77 15 62 0 ++++++++--------------------------------
6 files changed, 84 insertions(+), 131 deletions(-)
- retrieve from local storage (CT_GetLocal)
- save to local storage (CT_SaveLocal)
- retrieve from CVS (CT_GetCVS)
- make CT_GetFile and CT_GetCVS use CT_GetLocal and CT_SaveLocal
/trunk/scripts/functions | 126 91 35 0 +++++++++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 91 insertions(+), 35 deletions(-)
- vendor and alias must not contain spaces
- vendor must not contain dashes '-'
- sed_expr must not generate an alias with a space in it
/trunk/scripts/functions | 17 16 1 0 ++++++++++++++++-
/trunk/config/toolchain.in | 1 1 0 0 +
2 files changed, 17 insertions(+), 1 deletion(-)
- Not only will it give us full-qualified tuples, but it will also ensure
that they are valid tuples (in case of typo with user-provided tuples)
That's way better than trying to rewrite config.sub ourselves...
- use CT_BUILD_PREFIX and CT_BUILD_SUFFIX to call "gcc -dumpmachine"
/trunk/scripts/crosstool.sh | 29 7 22 0 +++++++----------------------
1 file changed, 7 insertions(+), 22 deletions(-)
