diff options
Diffstat (limited to 'docs/B - Known issues.txt')
| -rw-r--r-- | docs/B - Known issues.txt | 254 |
1 files changed, 0 insertions, 254 deletions
diff --git a/docs/B - Known issues.txt b/docs/B - Known issues.txt deleted file mode 100644 index 1d2db198..00000000 --- a/docs/B - Known issues.txt +++ /dev/null @@ -1,254 +0,0 @@ -File.........: B - Known issues.txt -Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@free.fr> -License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5 - - -Known issues / -_____________/ - - -This files lists the known issues encountered while developing crosstool-NG, -but that could not be addressed before the release. - -The file has one section for each known issue, each section containing four -sub-sections: Symptoms, Explanations, Fix, and Workaround. - -Each section is separated from the others with a lines of at least 4 dashes. - -The following dummy section explains it all. - - -------------------------------- - Symptoms: - A one- or two-liner of what you would observe. - Usually, the error message you would see in the build logs. - - Explanations: - An as much as possible in-depth explanations of the context, why it - happens, what has been investigated so far, and possible orientations - as how to try to solve this (eg. URLs, code snippets...). - - Status: - Tells about the status of the issue: - UNCONFIRMED : missing information, or unable, to reproduce, but there - is consensus that there is an issue somewhere... - CURRENT : the issue is applicable. - DEPRECATED : the issue used to apply in some cases, but has not been - confirmed or reported again lately. - CLOSED : the issue is no longer valid, and a fix has been added - either as a patch to this component, and/or as a - workaround in the scripts and/or the configuration. - - Fix: - What you have to do to fix it, if at all possible. - The fact that there is a fix, and yet this is a known issue means that - time to incorporate the fix in crosstool-NG was missing, or planned for - a future release. - - Workaround: - What you can do to fix it *temporarily*, if at all possible. - A workaround is not a real fix, as it can break other parts of - crosstool-NG, but at least makes you going in your particular case. - -So now, on for the real issues... - --------------------------------- -Symptoms: - gcc is not found, although I *do* have gcc installed. - -Explanations: - This is an issue on at least RHEL systems, where gcc is a symlink to ccache. - Because crosstool-NG create links to gcc for the build and host environment, - those symlinks are in fact pointing to ccache, which then doesn't know how - to run the compiler. - - A possible fix could probably set the environment variable CCACHE_CC to the - actual compiler used. - -Status: - CURRENT - -Fix: - None known. - -Workaround: - Uninstall ccache. - --------------------------------- -Symptoms: - The extract and/or path steps fail under Cygwin. - -Explanations: - This is not related to crosstool-NG. Mounts under Cygwin are by default not - case-sensitive. You have to change a registry setting to disable - case-insensitivity. See: - http://cygwin.com/faq.html section 4, question 30. - -Status: - DEPRECATED - -Fix: - Change the registry value as per the instructions on the Cygwin website. - -Workaround: - None. - --------------------------------- -Symptoms: - uClibc fails to build under Cygwin. - -Explanations: - With uClibc, it is possible to build a cross-ldd. Unfortunately, it is - not (currently) possible to build this cross-ldd under Cygwin. - -Status: - DEPRECATED - -Fix: - None so far. - -Workaround: - Disable the cross-ldd build. - --------------------------------- -Symptoms: - On 64-bit build systems, the glibc build fails for - 64-bit targets, because it can not find libgcc. - -Explanations: - This issue has been observed when the companion libraries are built - statically. For an unknown reason, in this case, the libgcc built by the - core gcc is not located in the same place it is located when building - with shared companion libraries. - -Status: - DEPRECATED - -Fix: - None so far. - -Workaround: - Build shared companion libraries. - --------------------------------- -Symptoms: - libtool.m4: error: problem compiling FC test program - -Explanations: - The gcc build procedure tries to run a Fortran test to see if it has a - working native fortran compiler installed on the build machine, and it - can't find one. A native Fortran compiler is needed (seems to be needed) - to build the Fortran frontend of the cross-compiler. - Even if you don't want to build the Fortran frontend, gcc tries to see - if it has one, but fails. This is no problem, as the Fortran frontend - will not be built. There is nothing to be worry about (unless you do - want to build the Fortran frontend, of course). - -Status: - CURRENT - -Fix: - None so far. It's a spurious error, so there will probably never be - a fix for this issue. - -Workaround: - None needed, it's a spurious error. - --------------------------------- -Symptoms: - unable to detect the exception model - -Explanations: - On some architectures, proper stack unwinding (C++) requires that - setjmp/longjmp (sjlj) be used, while on other architectures do not - need sjlj. On some architectures, gcc is unable to determine whether - sjlj are needed or not. - -Status: - CURRENT - -Fix: - None so far. - -Workaround: - Trying setting use of sjlj to either 'Y' or 'N' (instead of the - default 'M') in the menuconfig, option CT_CC_GCC_SJLJ_EXCEPTIONS - labelled "Use sjlj for exceptions". - --------------------------------- -Symptoms: - configure: error: forced unwind support is required - -Explanations: - The issue seems to be related to building NPTL on old versions - of glibc on some architectures (seen on powerpc, s390, s390x and x86_64). - -Status: - CURRENT - -Fix: - None so far. It would require some glibc hacking. - -Workaround: - Try setting "Force unwind support" in the "C-library" menu. - --------------------------------- -Symptoms: - glibc start files and headers fail with: [/usr/include/limits.h] Error 1 - -Explanations: - Old glibc Makefiles break with make-3.82. - -Status: - CURRENT - -Fix: - None so far. It would require some glibc hacking. - -Workaround: - There two possible workarounds: - 1- ask crosstool-NG to build make-3.81 just for this build session: - Select the following options: - Paths and misc options ---> - [*] Try features marked as EXPERIMENTAL - Companion tools ---> - [*] Build some companion tools - [*] make - 2- manually install make-3.81 to take precedence over the system make. - --------------------------------- -Symptoms: - The build fails with "mixed implicit and normal rules. Stop." - -Explanations: - Old glibc Makefiles break with make-3.82. - -Status: - CURRENT - -Fix: - None so far. See above issue. - -Workaround: - See above issue. - --------------------------------- -Symptoms: - On x86_64 hosts with 32bit userspace the GMP build fails with: - configure: error: Oops, mp_limb_t is 32 bits, but the assembler code - in this configuration expects 64 bits. - You appear to have set $CFLAGS, perhaps you also need to tell GMP the - intended ABI, see "ABI and ISA" in the manual. - -Explanations: - "uname -m" detects x86_64 but the build host is really x86. - -Status: - CURRENT - -Fix: - None so far. See above issue. - -Workaround: - use "setarch i686 ct-ng build" - --------------------------------- |