docs/known-issues.txt
author "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sun Jan 04 22:17:53 2009 +0000 (2009-01-04)
changeset 1123 8c5881324a79
parent 771 e1287c6748c9
child 1218 6e15a14224ef
permissions -rw-r--r--
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(-)
yann@771
     1
This files lists the known issues encountered while developping crosstool-NG,
yann@771
     2
but that could not be addressed before the release.
yann@771
     3
yann@771
     4
The file has one section for each known issue, each section containing four
yann@771
     5
sub-sections: Symptoms, Explanations, Fix, and Workaround.
yann@771
     6
yann@771
     7
Each section is separated from the others with a lines of at least 4 dashes.
yann@771
     8
yann@771
     9
The following dummy section explains it all.
yann@771
    10
yann@771
    11
    --------------------------------
yann@771
    12
    Symptoms:
yann@771
    13
      A one-liner of what you would observe.
yann@771
    14
yann@771
    15
    Explanations:
yann@771
    16
      An as much as possible in-depth explanations of the context, why it
yann@771
    17
      happens, what has been investigated so far, and possible orientations
yann@771
    18
      as how to try to solve this (eg. URLs, code snippets...).
yann@771
    19
yann@771
    20
    Fix:
yann@771
    21
      What you have to do to fix it, if at all possible.
yann@771
    22
      The fact that there is a fix, and yet this is a known issue means that
yann@771
    23
      time to incorporate the fix in crosstool-NG was missing, or planned for
yann@771
    24
      a future release.
yann@771
    25
yann@771
    26
    Workaround:
yann@771
    27
      What you can do to fix it *temporarily*, if at all possible.
yann@771
    28
      A workaround is not a real fix, as it can break other parts of
yann@771
    29
      crosstool-NG, but at least makes you going in your particular case.
yann@771
    30
yann@771
    31
So now, on for the real issues...
yann@771
    32
yann@771
    33
--------------------------------
yann@771
    34
Symptoms:
yann@771
    35
  Seemingly native toolchains do not build.
yann@771
    36
yann@771
    37
Explanations:
yann@771
    38
  Seemingly native toolchains are toolchains that target the same architecture
yann@771
    39
  as the one it is built on, and on which it will run, but the machine tuple
yann@771
    40
  may be different (eg i686 vs. i386, or x86_64-unknown-linux-gnu vs.
yann@771
    41
  x86_64-pc-linux-gnu).
yann@771
    42
yann@771
    43
  This seems to happen when building glibc-2.7 based toolchains only, for
yann@771
    44
  x86 and for x86_64.
yann@771
    45
yann@771
    46
  Only the system part of the tuple (here, linux-gnu) needs to be the same to
yann@885
    47
  trigger the bug. Which means that building a tolchain for either x86 or
yann@885
    48
  x86_64 on either x86 or x86_64 breaks.
yann@771
    49
yann@771
    50
Fix:
yann@771
    51
  None known.
yann@771
    52
yann@771
    53
Workaround:
yann@771
    54
  If this happens for you, stick with glibc-2.6.1 for now.
yann@771
    55
  Or investigate! :-)
yann@771
    56
yann@771
    57
--------------------------------
yann@885
    58
Symptoms:
yann@885
    59
  gcc is not found, although I *do* have gcc installed.
yann@885
    60
yann@885
    61
Explanations:
yann@885
    62
  This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
yann@885
    63
  Because crosstool-NG create links to gcc for the build and host environment,
yann@885
    64
  those symlinks are in fact pointing to ccache, which then doesn't know how
yann@885
    65
  to run the compiler.
yann@885
    66
yann@885
    67
  A possible fix could probably set the environment variable CCACHE_CC to the
yann@885
    68
  actual compiler used.
yann@885
    69
yann@885
    70
Fix:
yann@885
    71
  None known.
yann@885
    72
yann@885
    73
Workaround:
yann@885
    74
  Uninstall ccache.
yann@885
    75
yann@885
    76
--------------------------------