yann@2076
|
1 |
File.........: B - Known issues.txt
|
yann@2076
|
2 |
Copyrigth....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
|
yann@2076
|
3 |
License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
|
yann@2076
|
4 |
|
yann@2076
|
5 |
|
yann@2076
|
6 |
Known issues /
|
yann@2076
|
7 |
_____________/
|
yann@2076
|
8 |
|
yann@2076
|
9 |
|
yann@2076
|
10 |
This files lists the known issues encountered while developping crosstool-NG,
|
yann@2076
|
11 |
but that could not be addressed before the release.
|
yann@2076
|
12 |
|
yann@2076
|
13 |
The file has one section for each known issue, each section containing four
|
yann@2076
|
14 |
sub-sections: Symptoms, Explanations, Fix, and Workaround.
|
yann@2076
|
15 |
|
yann@2076
|
16 |
Each section is separated from the others with a lines of at least 4 dashes.
|
yann@2076
|
17 |
|
yann@2076
|
18 |
The following dummy section explains it all.
|
yann@2076
|
19 |
|
yann@2076
|
20 |
--------------------------------
|
yann@2076
|
21 |
Symptoms:
|
yann@2076
|
22 |
A one-liner of what you would observe.
|
yann@2076
|
23 |
|
yann@2076
|
24 |
Explanations:
|
yann@2076
|
25 |
An as much as possible in-depth explanations of the context, why it
|
yann@2076
|
26 |
happens, what has been investigated so far, and possible orientations
|
yann@2076
|
27 |
as how to try to solve this (eg. URLs, code snippets...).
|
yann@2076
|
28 |
|
yann@2076
|
29 |
Fix:
|
yann@2076
|
30 |
What you have to do to fix it, if at all possible.
|
yann@2076
|
31 |
The fact that there is a fix, and yet this is a known issue means that
|
yann@2076
|
32 |
time to incorporate the fix in crosstool-NG was missing, or planned for
|
yann@2076
|
33 |
a future release.
|
yann@2076
|
34 |
|
yann@2076
|
35 |
Workaround:
|
yann@2076
|
36 |
What you can do to fix it *temporarily*, if at all possible.
|
yann@2076
|
37 |
A workaround is not a real fix, as it can break other parts of
|
yann@2076
|
38 |
crosstool-NG, but at least makes you going in your particular case.
|
yann@2076
|
39 |
|
yann@2076
|
40 |
So now, on for the real issues...
|
yann@2076
|
41 |
|
yann@2076
|
42 |
--------------------------------
|
yann@2076
|
43 |
Symptoms:
|
yann@2076
|
44 |
gcc is not found, although I *do* have gcc installed.
|
yann@2076
|
45 |
|
yann@2076
|
46 |
Explanations:
|
yann@2076
|
47 |
This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
|
yann@2076
|
48 |
Because crosstool-NG create links to gcc for the build and host environment,
|
yann@2076
|
49 |
those symlinks are in fact pointing to ccache, which then doesn't know how
|
yann@2076
|
50 |
to run the compiler.
|
yann@2076
|
51 |
|
yann@2076
|
52 |
A possible fix could probably set the environment variable CCACHE_CC to the
|
yann@2076
|
53 |
actual compiler used.
|
yann@2076
|
54 |
|
yann@2076
|
55 |
Fix:
|
yann@2076
|
56 |
None known.
|
yann@2076
|
57 |
|
yann@2076
|
58 |
Workaround:
|
yann@2076
|
59 |
Uninstall ccache.
|
yann@2076
|
60 |
|
yann@2076
|
61 |
--------------------------------
|
yann@2076
|
62 |
Symptoms:
|
yann@2076
|
63 |
The extract and/or path steps fail under Cygwin.
|
yann@2076
|
64 |
|
yann@2076
|
65 |
Explanations:
|
yann@2076
|
66 |
This is not related to crosstool-NG. Mounts under Cygwin are by default not
|
yann@2076
|
67 |
case-sensitive. You have to use so-called "managed" mounts. See:
|
yann@2076
|
68 |
http://cygwin.com/faq.html section 4, question 32.
|
yann@2076
|
69 |
|
yann@2076
|
70 |
Fix:
|
yann@2076
|
71 |
Use "managed" mounts for the directories where you build *and* install your
|
yann@2076
|
72 |
toolchains.
|
yann@2076
|
73 |
|
yann@2076
|
74 |
Workaround:
|
yann@2076
|
75 |
None.
|
yann@2076
|
76 |
|
yann@2076
|
77 |
--------------------------------
|
yann@2076
|
78 |
Symptoms:
|
yann@2076
|
79 |
uClibc fails to build under Cygwin.
|
yann@2076
|
80 |
|
yann@2076
|
81 |
Explanations:
|
yann@2076
|
82 |
With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
|
yann@2076
|
83 |
not (currently) possible to build this cross-ldd under Cygwin.
|
yann@2076
|
84 |
|
yann@2076
|
85 |
Fix:
|
yann@2076
|
86 |
None so far.
|
yann@2076
|
87 |
|
yann@2076
|
88 |
Workaround:
|
yann@2076
|
89 |
Disable the cross-ldd build.
|
yann@2076
|
90 |
|
yann@2076
|
91 |
--------------------------------
|
yann@2076
|
92 |
Symptoms:
|
yann@2076
|
93 |
On 64-bit build systems, the glibc (possibly eglibc too) build fails for
|
yann@2076
|
94 |
64-bit targets, because it can not find libgcc.
|
yann@2076
|
95 |
|
yann@2076
|
96 |
Explanations:
|
yann@2076
|
97 |
This issue has been observed when the companion libraries are built
|
yann@2076
|
98 |
statically. For an unknown reason, in this case, the libgcc built by the
|
yann@2076
|
99 |
core gcc is not located in the same place it is located when building
|
yann@2076
|
100 |
with shared companion libraries.
|
yann@2076
|
101 |
|
yann@2076
|
102 |
Fix:
|
yann@2076
|
103 |
None so far.
|
yann@2076
|
104 |
|
yann@2076
|
105 |
Workaround:
|
yann@2076
|
106 |
Build shared companion libraries.
|
yann@2076
|
107 |
|
yann@2076
|
108 |
--------------------------------
|
yann@2076
|
109 |
Symptoms:
|
yann@2076
|
110 |
While building the final gcc, I get an error message that ends with:
|
yann@2076
|
111 |
libtool.m4: error: problem compiling FC test program
|
yann@2076
|
112 |
|
yann@2076
|
113 |
Explanations:
|
yann@2076
|
114 |
The gcc build procedure tries to run a Fortran test to see if it has a
|
yann@2076
|
115 |
working native fortran compiler installed on the build machine, and it
|
yann@2076
|
116 |
can't find one. A native Fortran compiler is needed (seems to be neede)
|
yann@2076
|
117 |
to build the Fortran frontend of the cross-compiler.
|
yann@2076
|
118 |
Even if you don't want to build the Fortran frontend, gcc tries to see
|
yann@2076
|
119 |
if it has one, but fails. This is no problem, as the Fortran frontend
|
yann@2076
|
120 |
will not be built. There is nothing to be worry about (unless you do
|
yann@2076
|
121 |
want to build the Fortran frontend, of course).
|
yann@2076
|
122 |
|
yann@2076
|
123 |
Fix:
|
yann@2076
|
124 |
None so far. It's a spurious error, so there will probably never be
|
yann@2076
|
125 |
a fix for this issue.
|
yann@2076
|
126 |
|
yann@2076
|
127 |
Workaround:
|
yann@2076
|
128 |
None needed, it's a spurious error.
|
yann@2076
|
129 |
|
yann@2076
|
130 |
--------------------------------
|
yann@2076
|
131 |
Symptoms:
|
yann@2076
|
132 |
gcc barfs because it is "unable to detect the exception model".
|
yann@2076
|
133 |
|
yann@2076
|
134 |
Explanations:
|
yann@2076
|
135 |
On some architectures, proper stack unwinding (C++) requires that
|
yann@2076
|
136 |
setjmp/longjmp (sjlj) be used, while on other architectures do not
|
yann@2076
|
137 |
need sjlj. On some architectures, gcc is unable to determine whether
|
yann@2076
|
138 |
sjlj are needed or not.
|
yann@2076
|
139 |
|
yann@2076
|
140 |
Fix:
|
yann@2076
|
141 |
None so far.
|
yann@2076
|
142 |
|
yann@2076
|
143 |
Workaround:
|
yann@2076
|
144 |
Trying setting use of sjlj to either 'Y' or 'N' (instead of the
|
yann@2076
|
145 |
default 'M') in the menuconfig, option CT_CC_GCC_SJLJ_EXCEPTIONS
|
yann@2076
|
146 |
labelled "Use sjlj for exceptions".
|
yann@2076
|
147 |
|
yann@2076
|
148 |
--------------------------------
|