yann@771: This files lists the known issues encountered while developping crosstool-NG, yann@771: but that could not be addressed before the release. yann@771: yann@771: The file has one section for each known issue, each section containing four yann@771: sub-sections: Symptoms, Explanations, Fix, and Workaround. yann@771: yann@771: Each section is separated from the others with a lines of at least 4 dashes. yann@771: yann@771: The following dummy section explains it all. yann@771: yann@771: -------------------------------- yann@771: Symptoms: yann@771: A one-liner of what you would observe. yann@771: yann@771: Explanations: yann@771: An as much as possible in-depth explanations of the context, why it yann@771: happens, what has been investigated so far, and possible orientations yann@771: as how to try to solve this (eg. URLs, code snippets...). yann@771: yann@771: Fix: yann@771: What you have to do to fix it, if at all possible. yann@771: The fact that there is a fix, and yet this is a known issue means that yann@771: time to incorporate the fix in crosstool-NG was missing, or planned for yann@771: a future release. yann@771: yann@771: Workaround: yann@771: What you can do to fix it *temporarily*, if at all possible. yann@771: A workaround is not a real fix, as it can break other parts of yann@771: crosstool-NG, but at least makes you going in your particular case. yann@771: yann@771: So now, on for the real issues... yann@771: yann@771: -------------------------------- yann@771: Symptoms: yann@885: gcc is not found, although I *do* have gcc installed. yann@885: yann@885: Explanations: yann@885: This is an issue on at least RHEL systems, where gcc is a symlink to ccache. yann@885: Because crosstool-NG create links to gcc for the build and host environment, yann@885: those symlinks are in fact pointing to ccache, which then doesn't know how yann@885: to run the compiler. yann@885: yann@885: A possible fix could probably set the environment variable CCACHE_CC to the yann@885: actual compiler used. yann@885: yann@885: Fix: yann@885: None known. yann@885: yann@885: Workaround: yann@885: Uninstall ccache. yann@885: yann@885: -------------------------------- yann@1218: Symptoms: yann@1280: The extract and/or path steps fail under Cygwin. yann@1218: yann@1218: Explanations: yann@1218: This is not related to crosstool-NG. Mounts under Cygwin are by default not yann@1218: case-sensitive. You have to use so-called "managed" mounts. See: yann@1218: http://cygwin.com/faq.html section 4, question 32. yann@1218: yann@1218: Fix: yann@1218: Use "managed" mounts for the directories where you build *and* install your yann@1218: toolchains. yann@1218: yann@1218: Workaround: yann@1218: None. yann@1218: yann@1218: -------------------------------- yann@1280: Symptoms: yann@1280: uClibc fails to build under Cygwin. yann@1280: yann@1280: Explanations: yann@1280: With uClibc, it is possible to build a cross-ldd. Unfortunately, it is yann@1280: not (currently) possible to build this cross-ldd under Cygwin. yann@1280: yann@1280: Fix: yann@1280: None so far. yann@1280: yann@1280: Workaround: yann@1280: Disable the cross-ldd build. yann@1280: yann@1280: -------------------------------- yann@1942: Symptoms: yann@1942: On 64-bit build systems, the glibc (possibly eglibc too) build fails for yann@1942: 64-bit targets, because it can not find libgcc. yann@1942: yann@1942: Explanations: yann@1942: This issue has been observed when the companion libraries are built yann@1942: statically. For an unknown reason, in this case, the libgcc built by the yann@1942: core gcc is not located in the same place it is located when building yann@1942: with shared companion libraries. yann@1942: yann@1942: Fix: yann@1942: None so far. yann@1942: yann@1942: Workaround: yann@1942: Build shared companion libraries. yann@1942: yann@1942: -------------------------------- yann@2032: Symptoms: yann@2032: While building the final gcc, I get an error message that ends with: yann@2032: libtool.m4: error: problem compiling FC test program yann@2032: yann@2032: Explanations: yann@2056: The gcc build procedure tries to run a Fortran test to see if it has a yann@2032: working native fortran compiler installed on the build machine, and it yann@2056: can't find one. A native Fortran compiler is needed (seems to be neede) yann@2056: to build the Fortran frontend of the cross-compiler. yann@2032: Even if you don't want to build the Fortran frontend, gcc tries to see yann@2032: if it has one, but fails. This is no problem, as the Fortran frontend yann@2032: will not be built. There is nothing to be worry about (unless you do yann@2032: want to build the Fortran frontend, of course). yann@2032: yann@2032: Fix: yann@2032: None so far. It's a spurious error, so there will probably never be yann@2032: a fix for this issue. yann@2032: yann@2032: Workaround: yann@2032: None needed, it's a spurious error. yann@2032: yann@2032: -------------------------------- yann@2056: Symptoms: yann@2056: gcc barfs because it is "unable to detect the exception model". yann@2056: yann@2056: Explanations: yann@2056: On some architectures, proper stack unwinding (C++) requires that yann@2056: setjmp/longjmp (sjlj) be used, while on other architectures do not yann@2056: need sjlj. On some architectures, gcc is unable to determine whether yann@2056: sjlj are needed or not. yann@2056: yann@2056: Fix: yann@2056: None so far. yann@2056: yann@2056: Workaround: yann@2056: Trying setting use of sjlj to either 'Y' or 'N' (instead of the yann@2056: default 'M') in the menuconfig, option CT_CC_GCC_SJLJ_EXCEPTIONS yann@2056: labelled "Use sjlj for exceptions". yann@2056: yann@2056: --------------------------------