mirror of
https://github.com/crosstool-ng/crosstool-ng.git
synced 2024-12-18 20:37:56 +00:00
ffee93e4d2
Since anciens.enib.fr has been dead for two months now, without any hope of recovery, update my e-mail to point to @free.fr instead. Reported-by: "Bryan Hundven" <bryanhundven@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
256 lines
7.1 KiB
Plaintext
256 lines
7.1 KiB
Plaintext
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"
|
|
|
|
--------------------------------
|