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.
Fix: None known.
Workaround: Uninstall ccache.
Build fails with:
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.
Fix: None so far.
Trying setting use of sjlj to either ‘Y’ or ‘N’ (instead of the
default ‘M’) in the menuconfig, option
labeled “Use sjlj for exceptions”.
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.
uname -m detects x86_64 but the build host is really x86.
Fix: None so far. See above issue.
Workaround: use “setarch i686 ct-ng build”