yann@2076: File.........: B - Known issues.txt antony@2563: Copyright....: (C) 2010 Yann E. MORIN yann@2076: License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5 yann@2076: yann@2076: yann@2076: Known issues / yann@2076: _____________/ yann@2076: yann@2076: antony@2564: This files lists the known issues encountered while developing crosstool-NG, yann@2076: but that could not be addressed before the release. yann@2076: yann@2076: The file has one section for each known issue, each section containing four yann@2076: sub-sections: Symptoms, Explanations, Fix, and Workaround. yann@2076: yann@2076: Each section is separated from the others with a lines of at least 4 dashes. yann@2076: yann@2076: The following dummy section explains it all. yann@2076: yann@2076: -------------------------------- yann@2076: Symptoms: yann@2386: A one- or two-liner of what you would observe. yann@2386: Usually, the error message you would see in the build logs. yann@2076: yann@2076: Explanations: yann@2076: An as much as possible in-depth explanations of the context, why it yann@2076: happens, what has been investigated so far, and possible orientations yann@2076: as how to try to solve this (eg. URLs, code snippets...). yann@2076: yann@2387: Status: yann@2387: Tells about the status of the issue: yann@2387: UNCONFIRMED : missing information, or unable, to reproduce, but there yann@2387: is consensus that there is an issue somewhere... yann@2387: CURRENT : the issue is applicable. yann@2387: DEPRECATED : the issue used to apply in some cases, but has not been yann@2387: confirmed or reported again lately. yann@2387: CLOSED : the issue is no longer valid, and a fix has been added yann@2387: either as a patch to this component, and/or as a yann@2387: workaround in the scripts and/or the configuration. yann@2387: yann@2076: Fix: yann@2076: What you have to do to fix it, if at all possible. yann@2076: The fact that there is a fix, and yet this is a known issue means that yann@2076: time to incorporate the fix in crosstool-NG was missing, or planned for yann@2076: a future release. yann@2076: yann@2076: Workaround: yann@2076: What you can do to fix it *temporarily*, if at all possible. yann@2076: A workaround is not a real fix, as it can break other parts of yann@2076: crosstool-NG, but at least makes you going in your particular case. yann@2076: yann@2076: So now, on for the real issues... yann@2076: yann@2076: -------------------------------- yann@2076: Symptoms: yann@2076: gcc is not found, although I *do* have gcc installed. yann@2076: yann@2076: Explanations: yann@2076: This is an issue on at least RHEL systems, where gcc is a symlink to ccache. yann@2076: Because crosstool-NG create links to gcc for the build and host environment, yann@2076: those symlinks are in fact pointing to ccache, which then doesn't know how yann@2076: to run the compiler. yann@2076: yann@2076: A possible fix could probably set the environment variable CCACHE_CC to the yann@2076: actual compiler used. yann@2076: yann@2387: Status: yann@2387: CURRENT yann@2387: yann@2076: Fix: yann@2076: None known. yann@2076: yann@2076: Workaround: yann@2076: Uninstall ccache. yann@2076: yann@2076: -------------------------------- yann@2076: Symptoms: yann@2076: The extract and/or path steps fail under Cygwin. yann@2076: yann@2076: Explanations: yann@2076: This is not related to crosstool-NG. Mounts under Cygwin are by default not yann@2076: case-sensitive. You have to use so-called "managed" mounts. See: yann@2076: http://cygwin.com/faq.html section 4, question 32. yann@2076: yann@2387: Status: yann@2387: DEPRECATED yann@2387: yann@2076: Fix: yann@2076: Use "managed" mounts for the directories where you build *and* install your yann@2076: toolchains. yann@2076: yann@2076: Workaround: yann@2076: None. yann@2076: yann@2076: -------------------------------- yann@2076: Symptoms: yann@2076: uClibc fails to build under Cygwin. yann@2076: yann@2076: Explanations: yann@2076: With uClibc, it is possible to build a cross-ldd. Unfortunately, it is yann@2076: not (currently) possible to build this cross-ldd under Cygwin. yann@2076: yann@2387: Status: yann@2387: DEPRECATED yann@2387: yann@2076: Fix: yann@2076: None so far. yann@2076: yann@2076: Workaround: yann@2076: Disable the cross-ldd build. yann@2076: yann@2076: -------------------------------- yann@2076: Symptoms: yann@2076: On 64-bit build systems, the glibc (possibly eglibc too) build fails for yann@2076: 64-bit targets, because it can not find libgcc. yann@2076: yann@2076: Explanations: yann@2076: This issue has been observed when the companion libraries are built yann@2076: statically. For an unknown reason, in this case, the libgcc built by the yann@2076: core gcc is not located in the same place it is located when building yann@2076: with shared companion libraries. yann@2076: yann@2387: Status: yann@2387: DEPRECATED yann@2387: yann@2076: Fix: yann@2076: None so far. yann@2076: yann@2076: Workaround: yann@2076: Build shared companion libraries. yann@2076: yann@2076: -------------------------------- yann@2076: Symptoms: yann@2386: libtool.m4: error: problem compiling FC test program yann@2076: yann@2076: Explanations: yann@2076: The gcc build procedure tries to run a Fortran test to see if it has a yann@2076: working native fortran compiler installed on the build machine, and it antony@2564: can't find one. A native Fortran compiler is needed (seems to be needed) yann@2076: to build the Fortran frontend of the cross-compiler. yann@2076: Even if you don't want to build the Fortran frontend, gcc tries to see yann@2076: if it has one, but fails. This is no problem, as the Fortran frontend yann@2076: will not be built. There is nothing to be worry about (unless you do yann@2076: want to build the Fortran frontend, of course). yann@2076: yann@2387: Status: yann@2387: CURRENT yann@2387: yann@2076: Fix: yann@2076: None so far. It's a spurious error, so there will probably never be yann@2076: a fix for this issue. yann@2076: yann@2076: Workaround: yann@2076: None needed, it's a spurious error. yann@2076: yann@2076: -------------------------------- yann@2076: Symptoms: yann@2386: unable to detect the exception model yann@2076: yann@2076: Explanations: yann@2076: On some architectures, proper stack unwinding (C++) requires that yann@2076: setjmp/longjmp (sjlj) be used, while on other architectures do not yann@2076: need sjlj. On some architectures, gcc is unable to determine whether yann@2076: sjlj are needed or not. yann@2076: yann@2387: Status: yann@2387: CURRENT yann@2387: yann@2076: Fix: yann@2076: None so far. yann@2076: yann@2076: Workaround: yann@2076: Trying setting use of sjlj to either 'Y' or 'N' (instead of the yann@2076: default 'M') in the menuconfig, option CT_CC_GCC_SJLJ_EXCEPTIONS yann@2076: labelled "Use sjlj for exceptions". yann@2076: yann@2076: -------------------------------- yann@2384: Symptoms: yann@2386: configure: error: forced unwind support is required yann@2384: yann@2384: Explanations: yann@2384: The issue seems to be related to building NPTL on old versions yann@2384: of glibc (and possibly eglibc as well) on some architectures yann@2384: (seen on powerpc, s390, s390x and x86_64). yann@2384: yann@2387: Status: yann@2387: CURRENT yann@2387: yann@2384: Fix: yann@2384: None so far. It would require some glibc hacking. yann@2384: yann@2384: Workaround: yann@2384: Try setting "Force unwind support" in the "C-library" menu. yann@2384: yann@2384: -------------------------------- yann@2565: Symptoms: yann@2565: glibc start files and headers fail with: [/usr/include/limits.h] Error 1 yann@2565: yann@2565: Explanations: yann@2565: The glibc Makefiles break with make-3.82. yann@2565: yann@2565: Status: yann@2565: CURRENT yann@2565: yann@2565: Fix: yann@2565: None so far. It would require some glibc hacking. yann@2565: yann@2565: Workaround: yann@2565: There two possible workarounds: yann@2565: 1- ask crosstool-NG to build make-3.81 just for this build session; yann@2565: 2- manually install make-3.81 to take precedence over the system make. yann@2565: yann@2565: --------------------------------