| 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 use so-called "managed" mounts. See: |
| http://cygwin.com/faq.html section 4, question 32. |
| |
| Status: |
| DEPRECATED |
| |
| Fix: |
| Use "managed" mounts for the directories where you build *and* install your |
| toolchains. |
| |
| 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 (possibly eglibc too) 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 (and possibly eglibc as well) 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 (and eglibc) Makefiles break with make-3.82. |
| |
| Status: |
| CURRENT |
| |
| Fix: |
| None so far. It would require some glibc/eglibc 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 (and eglibc) 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" |
| |
| -------------------------------- |