docs/B - Known issues.txt
changeset 2076 b58109b7b321
child 2384 5f260bb27b35
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/B - Known issues.txt	Sat Aug 14 16:37:11 2010 +0200
     1.3 @@ -0,0 +1,148 @@
     1.4 +File.........: B - Known issues.txt
     1.5 +Copyrigth....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
     1.6 +License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
     1.7 +
     1.8 +
     1.9 +Known issues  /
    1.10 +_____________/
    1.11 +
    1.12 +
    1.13 +This files lists the known issues encountered while developping crosstool-NG,
    1.14 +but that could not be addressed before the release.
    1.15 +
    1.16 +The file has one section for each known issue, each section containing four
    1.17 +sub-sections: Symptoms, Explanations, Fix, and Workaround.
    1.18 +
    1.19 +Each section is separated from the others with a lines of at least 4 dashes.
    1.20 +
    1.21 +The following dummy section explains it all.
    1.22 +
    1.23 +    --------------------------------
    1.24 +    Symptoms:
    1.25 +      A one-liner of what you would observe.
    1.26 +
    1.27 +    Explanations:
    1.28 +      An as much as possible in-depth explanations of the context, why it
    1.29 +      happens, what has been investigated so far, and possible orientations
    1.30 +      as how to try to solve this (eg. URLs, code snippets...).
    1.31 +
    1.32 +    Fix:
    1.33 +      What you have to do to fix it, if at all possible.
    1.34 +      The fact that there is a fix, and yet this is a known issue means that
    1.35 +      time to incorporate the fix in crosstool-NG was missing, or planned for
    1.36 +      a future release.
    1.37 +
    1.38 +    Workaround:
    1.39 +      What you can do to fix it *temporarily*, if at all possible.
    1.40 +      A workaround is not a real fix, as it can break other parts of
    1.41 +      crosstool-NG, but at least makes you going in your particular case.
    1.42 +
    1.43 +So now, on for the real issues...
    1.44 +
    1.45 +--------------------------------
    1.46 +Symptoms:
    1.47 +  gcc is not found, although I *do* have gcc installed.
    1.48 +
    1.49 +Explanations:
    1.50 +  This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
    1.51 +  Because crosstool-NG create links to gcc for the build and host environment,
    1.52 +  those symlinks are in fact pointing to ccache, which then doesn't know how
    1.53 +  to run the compiler.
    1.54 +
    1.55 +  A possible fix could probably set the environment variable CCACHE_CC to the
    1.56 +  actual compiler used.
    1.57 +
    1.58 +Fix:
    1.59 +  None known.
    1.60 +
    1.61 +Workaround:
    1.62 +  Uninstall ccache.
    1.63 +
    1.64 +--------------------------------
    1.65 +Symptoms:
    1.66 +  The extract and/or path steps fail under Cygwin.
    1.67 +
    1.68 +Explanations:
    1.69 +  This is not related to crosstool-NG. Mounts under Cygwin are by default not
    1.70 +  case-sensitive. You have to use so-called "managed" mounts. See:
    1.71 +  http://cygwin.com/faq.html section 4, question 32.
    1.72 +
    1.73 +Fix:
    1.74 +  Use "managed" mounts for the directories where you build *and* install your
    1.75 +  toolchains.
    1.76 +
    1.77 +Workaround:
    1.78 +  None.
    1.79 +
    1.80 +--------------------------------
    1.81 +Symptoms:
    1.82 +  uClibc fails to build under Cygwin.
    1.83 +
    1.84 +Explanations:
    1.85 +  With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
    1.86 +  not (currently) possible to build this cross-ldd under Cygwin.
    1.87 +
    1.88 +Fix:
    1.89 +  None so far.
    1.90 +
    1.91 +Workaround:
    1.92 +  Disable the cross-ldd build.
    1.93 +
    1.94 +--------------------------------
    1.95 +Symptoms:
    1.96 +  On 64-bit build systems, the glibc (possibly eglibc too) build fails for
    1.97 +  64-bit targets, because it can not find libgcc.
    1.98 +
    1.99 +Explanations:
   1.100 +  This issue has been observed when the companion libraries are built
   1.101 +  statically. For an unknown reason, in this case, the libgcc built by the
   1.102 +  core gcc is not located in the same place it is located when building
   1.103 +  with shared companion libraries.
   1.104 +
   1.105 +Fix:
   1.106 +  None so far.
   1.107 +
   1.108 +Workaround:
   1.109 +  Build shared companion libraries.
   1.110 +
   1.111 +--------------------------------
   1.112 +Symptoms:
   1.113 +  While building the final gcc, I get an error message that ends with:
   1.114 +    libtool.m4: error: problem compiling FC test program
   1.115 +
   1.116 +Explanations:
   1.117 +  The gcc build procedure tries to run a Fortran test to see if it has a
   1.118 +  working native fortran compiler installed on the build machine, and it
   1.119 +  can't find one. A native Fortran compiler is needed (seems to be neede)
   1.120 +  to build the Fortran frontend of the cross-compiler.
   1.121 +  Even if you don't want to build the Fortran frontend, gcc tries to see
   1.122 +  if it has one, but fails. This is no problem, as the Fortran frontend
   1.123 +  will not be built. There is nothing to be worry about (unless you do
   1.124 +  want to build the Fortran frontend, of course).
   1.125 +
   1.126 +Fix:
   1.127 +  None so far. It's a spurious error, so there will probably never be
   1.128 +  a fix for this issue.
   1.129 +
   1.130 +Workaround:
   1.131 +  None needed, it's a spurious error.
   1.132 +
   1.133 +--------------------------------
   1.134 +Symptoms:
   1.135 +  gcc barfs because it is "unable to detect the exception model".
   1.136 +
   1.137 +Explanations:
   1.138 +  On some architectures, proper stack unwinding (C++) requires that
   1.139 +  setjmp/longjmp (sjlj) be used, while on other architectures do not
   1.140 +  need sjlj. On some architectures, gcc is unable to determine whether
   1.141 +  sjlj are needed or not.
   1.142 +
   1.143 +Fix:
   1.144 +  None so far.
   1.145 +
   1.146 +Workaround:
   1.147 +  Trying setting use of sjlj to either 'Y' or 'N' (instead of the
   1.148 +  default 'M') in the menuconfig, option CT_CC_GCC_SJLJ_EXCEPTIONS
   1.149 +  labelled "Use sjlj for exceptions".
   1.150 +
   1.151 +--------------------------------