1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/B - Known issues.txt Thu Apr 07 11:52:23 2011 +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 +--------------------------------