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