Get rid of CT_LIBC_FILE, remove useless CT_MakeAbsolutePath.
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(-)
1 This files lists the known issues encountered while developping crosstool-NG,
2 but that could not be addressed before the release.
4 The file has one section for each known issue, each section containing four
5 sub-sections: Symptoms, Explanations, Fix, and Workaround.
7 Each section is separated from the others with a lines of at least 4 dashes.
9 The following dummy section explains it all.
11 --------------------------------
13 A one-liner of what you would observe.
16 An as much as possible in-depth explanations of the context, why it
17 happens, what has been investigated so far, and possible orientations
18 as how to try to solve this (eg. URLs, code snippets...).
21 What you have to do to fix it, if at all possible.
22 The fact that there is a fix, and yet this is a known issue means that
23 time to incorporate the fix in crosstool-NG was missing, or planned for
27 What you can do to fix it *temporarily*, if at all possible.
28 A workaround is not a real fix, as it can break other parts of
29 crosstool-NG, but at least makes you going in your particular case.
31 So now, on for the real issues...
33 --------------------------------
35 Seemingly native toolchains do not build.
38 Seemingly native toolchains are toolchains that target the same architecture
39 as the one it is built on, and on which it will run, but the machine tuple
40 may be different (eg i686 vs. i386, or x86_64-unknown-linux-gnu vs.
43 This seems to happen when building glibc-2.7 based toolchains only, for
46 Only the system part of the tuple (here, linux-gnu) needs to be the same to
47 trigger the bug. Which means that building a tolchain for either x86 or
48 x86_64 on either x86 or x86_64 breaks.
54 If this happens for you, stick with glibc-2.6.1 for now.
57 --------------------------------
59 gcc is not found, although I *do* have gcc installed.
62 This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
63 Because crosstool-NG create links to gcc for the build and host environment,
64 those symlinks are in fact pointing to ccache, which then doesn't know how
67 A possible fix could probably set the environment variable CCACHE_CC to the
76 --------------------------------