Push the calculation of the tuple's kernel part down to kernel's build scripts:
- update the kernel script's API with the function CT_DiKernelTupleValues
- update doc accordingly (also with the architecture change, missing in the previous commit)
- small clean-up in the main script, remove useless test

/trunk/scripts/build/kernel/bare-metal.sh | 5 5 0 0 +++++
/trunk/scripts/build/kernel/linux.sh | 5 5 0 0 +++++
/trunk/scripts/crosstool.sh | 31 13 18 0 +++++++++++++------------------
/trunk/scripts/functions | 15 8 7 0 ++++++++-------
/trunk/docs/overview.txt | 13 9 4 0 +++++++++----
5 files changed, 40 insertions(+), 29 deletions(-)

http://mirror.sh-linux.org/rpm-2003/SRPMS/gcc-3.2.3-3.src.rpm contains the following patches:

gcc-20030210-sh-linux-1.patch

gcc-3.2.3-libffi-1.patch

gcc-3.2.3-sh-linux-dwarf2-1.patch (*not* applied by the spec file, it's in there by accident)

gcc-3.2.3-libffi-1.patch was needed just to build, I think.

After that was applied, sh4 gcc seemed to compile fine, but c++ programs

failed to execute because libstdc++.so.5 was built without version

info.  This was caused directly by libstdc++-v3/configure setting

SYMVER_MAP=config/linker-map.dummy because it sees that 

no libgcc_s.so was generated; configure says

  checking for shared libgcc... no.

Applying gcc-20030210-sh-linux-1.patch in hopes it makes those problems go away.