yann@2076
|
1 |
File.........: B - Known issues.txt
|
yann@2908
|
2 |
Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@free.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 |
|
antony@2564
|
10 |
This files lists the known issues encountered while developing 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@2386
|
22 |
A one- or two-liner of what you would observe.
|
yann@2386
|
23 |
Usually, the error message you would see in the build logs.
|
yann@2076
|
24 |
|
yann@2076
|
25 |
Explanations:
|
yann@2076
|
26 |
An as much as possible in-depth explanations of the context, why it
|
yann@2076
|
27 |
happens, what has been investigated so far, and possible orientations
|
yann@2076
|
28 |
as how to try to solve this (eg. URLs, code snippets...).
|
yann@2076
|
29 |
|
yann@2387
|
30 |
Status:
|
yann@2387
|
31 |
Tells about the status of the issue:
|
yann@2387
|
32 |
UNCONFIRMED : missing information, or unable, to reproduce, but there
|
yann@2387
|
33 |
is consensus that there is an issue somewhere...
|
yann@2387
|
34 |
CURRENT : the issue is applicable.
|
yann@2387
|
35 |
DEPRECATED : the issue used to apply in some cases, but has not been
|
yann@2387
|
36 |
confirmed or reported again lately.
|
yann@2387
|
37 |
CLOSED : the issue is no longer valid, and a fix has been added
|
yann@2387
|
38 |
either as a patch to this component, and/or as a
|
yann@2387
|
39 |
workaround in the scripts and/or the configuration.
|
yann@2387
|
40 |
|
yann@2076
|
41 |
Fix:
|
yann@2076
|
42 |
What you have to do to fix it, if at all possible.
|
yann@2076
|
43 |
The fact that there is a fix, and yet this is a known issue means that
|
yann@2076
|
44 |
time to incorporate the fix in crosstool-NG was missing, or planned for
|
yann@2076
|
45 |
a future release.
|
yann@2076
|
46 |
|
yann@2076
|
47 |
Workaround:
|
yann@2076
|
48 |
What you can do to fix it *temporarily*, if at all possible.
|
yann@2076
|
49 |
A workaround is not a real fix, as it can break other parts of
|
yann@2076
|
50 |
crosstool-NG, but at least makes you going in your particular case.
|
yann@2076
|
51 |
|
yann@2076
|
52 |
So now, on for the real issues...
|
yann@2076
|
53 |
|
yann@2076
|
54 |
--------------------------------
|
yann@2076
|
55 |
Symptoms:
|
yann@2076
|
56 |
gcc is not found, although I *do* have gcc installed.
|
yann@2076
|
57 |
|
yann@2076
|
58 |
Explanations:
|
yann@2076
|
59 |
This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
|
yann@2076
|
60 |
Because crosstool-NG create links to gcc for the build and host environment,
|
yann@2076
|
61 |
those symlinks are in fact pointing to ccache, which then doesn't know how
|
yann@2076
|
62 |
to run the compiler.
|
yann@2076
|
63 |
|
yann@2076
|
64 |
A possible fix could probably set the environment variable CCACHE_CC to the
|
yann@2076
|
65 |
actual compiler used.
|
yann@2076
|
66 |
|
yann@2387
|
67 |
Status:
|
yann@2387
|
68 |
CURRENT
|
yann@2387
|
69 |
|
yann@2076
|
70 |
Fix:
|
yann@2076
|
71 |
None known.
|
yann@2076
|
72 |
|
yann@2076
|
73 |
Workaround:
|
yann@2076
|
74 |
Uninstall ccache.
|
yann@2076
|
75 |
|
yann@2076
|
76 |
--------------------------------
|
yann@2076
|
77 |
Symptoms:
|
yann@2076
|
78 |
The extract and/or path steps fail under Cygwin.
|
yann@2076
|
79 |
|
yann@2076
|
80 |
Explanations:
|
yann@2076
|
81 |
This is not related to crosstool-NG. Mounts under Cygwin are by default not
|
yann@2076
|
82 |
case-sensitive. You have to use so-called "managed" mounts. See:
|
yann@2076
|
83 |
http://cygwin.com/faq.html section 4, question 32.
|
yann@2076
|
84 |
|
yann@2387
|
85 |
Status:
|
yann@2387
|
86 |
DEPRECATED
|
yann@2387
|
87 |
|
yann@2076
|
88 |
Fix:
|
yann@2076
|
89 |
Use "managed" mounts for the directories where you build *and* install your
|
yann@2076
|
90 |
toolchains.
|
yann@2076
|
91 |
|
yann@2076
|
92 |
Workaround:
|
yann@2076
|
93 |
None.
|
yann@2076
|
94 |
|
yann@2076
|
95 |
--------------------------------
|
yann@2076
|
96 |
Symptoms:
|
yann@2076
|
97 |
uClibc fails to build under Cygwin.
|
yann@2076
|
98 |
|
yann@2076
|
99 |
Explanations:
|
yann@2076
|
100 |
With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
|
yann@2076
|
101 |
not (currently) possible to build this cross-ldd under Cygwin.
|
yann@2076
|
102 |
|
yann@2387
|
103 |
Status:
|
yann@2387
|
104 |
DEPRECATED
|
yann@2387
|
105 |
|
yann@2076
|
106 |
Fix:
|
yann@2076
|
107 |
None so far.
|
yann@2076
|
108 |
|
yann@2076
|
109 |
Workaround:
|
yann@2076
|
110 |
Disable the cross-ldd build.
|
yann@2076
|
111 |
|
yann@2076
|
112 |
--------------------------------
|
yann@2076
|
113 |
Symptoms:
|
yann@2076
|
114 |
On 64-bit build systems, the glibc (possibly eglibc too) build fails for
|
yann@2076
|
115 |
64-bit targets, because it can not find libgcc.
|
yann@2076
|
116 |
|
yann@2076
|
117 |
Explanations:
|
yann@2076
|
118 |
This issue has been observed when the companion libraries are built
|
yann@2076
|
119 |
statically. For an unknown reason, in this case, the libgcc built by the
|
yann@2076
|
120 |
core gcc is not located in the same place it is located when building
|
yann@2076
|
121 |
with shared companion libraries.
|
yann@2076
|
122 |
|
yann@2387
|
123 |
Status:
|
yann@2387
|
124 |
DEPRECATED
|
yann@2387
|
125 |
|
yann@2076
|
126 |
Fix:
|
yann@2076
|
127 |
None so far.
|
yann@2076
|
128 |
|
yann@2076
|
129 |
Workaround:
|
yann@2076
|
130 |
Build shared companion libraries.
|
yann@2076
|
131 |
|
yann@2076
|
132 |
--------------------------------
|
yann@2076
|
133 |
Symptoms:
|
yann@2386
|
134 |
libtool.m4: error: problem compiling FC test program
|
yann@2076
|
135 |
|
yann@2076
|
136 |
Explanations:
|
yann@2076
|
137 |
The gcc build procedure tries to run a Fortran test to see if it has a
|
yann@2076
|
138 |
working native fortran compiler installed on the build machine, and it
|
antony@2564
|
139 |
can't find one. A native Fortran compiler is needed (seems to be needed)
|
yann@2076
|
140 |
to build the Fortran frontend of the cross-compiler.
|
yann@2076
|
141 |
Even if you don't want to build the Fortran frontend, gcc tries to see
|
yann@2076
|
142 |
if it has one, but fails. This is no problem, as the Fortran frontend
|
yann@2076
|
143 |
will not be built. There is nothing to be worry about (unless you do
|
yann@2076
|
144 |
want to build the Fortran frontend, of course).
|
yann@2076
|
145 |
|
yann@2387
|
146 |
Status:
|
yann@2387
|
147 |
CURRENT
|
yann@2387
|
148 |
|
yann@2076
|
149 |
Fix:
|
yann@2076
|
150 |
None so far. It's a spurious error, so there will probably never be
|
yann@2076
|
151 |
a fix for this issue.
|
yann@2076
|
152 |
|
yann@2076
|
153 |
Workaround:
|
yann@2076
|
154 |
None needed, it's a spurious error.
|
yann@2076
|
155 |
|
yann@2076
|
156 |
--------------------------------
|
yann@2076
|
157 |
Symptoms:
|
yann@2386
|
158 |
unable to detect the exception model
|
yann@2076
|
159 |
|
yann@2076
|
160 |
Explanations:
|
yann@2076
|
161 |
On some architectures, proper stack unwinding (C++) requires that
|
yann@2076
|
162 |
setjmp/longjmp (sjlj) be used, while on other architectures do not
|
yann@2076
|
163 |
need sjlj. On some architectures, gcc is unable to determine whether
|
yann@2076
|
164 |
sjlj are needed or not.
|
yann@2076
|
165 |
|
yann@2387
|
166 |
Status:
|
yann@2387
|
167 |
CURRENT
|
yann@2387
|
168 |
|
yann@2076
|
169 |
Fix:
|
yann@2076
|
170 |
None so far.
|
yann@2076
|
171 |
|
yann@2076
|
172 |
Workaround:
|
yann@2076
|
173 |
Trying setting use of sjlj to either 'Y' or 'N' (instead of the
|
yann@2076
|
174 |
default 'M') in the menuconfig, option CT_CC_GCC_SJLJ_EXCEPTIONS
|
yann@2076
|
175 |
labelled "Use sjlj for exceptions".
|
yann@2076
|
176 |
|
yann@2076
|
177 |
--------------------------------
|
yann@2384
|
178 |
Symptoms:
|
yann@2386
|
179 |
configure: error: forced unwind support is required
|
yann@2384
|
180 |
|
yann@2384
|
181 |
Explanations:
|
yann@2384
|
182 |
The issue seems to be related to building NPTL on old versions
|
yann@2384
|
183 |
of glibc (and possibly eglibc as well) on some architectures
|
yann@2384
|
184 |
(seen on powerpc, s390, s390x and x86_64).
|
yann@2384
|
185 |
|
yann@2387
|
186 |
Status:
|
yann@2387
|
187 |
CURRENT
|
yann@2387
|
188 |
|
yann@2384
|
189 |
Fix:
|
yann@2384
|
190 |
None so far. It would require some glibc hacking.
|
yann@2384
|
191 |
|
yann@2384
|
192 |
Workaround:
|
yann@2384
|
193 |
Try setting "Force unwind support" in the "C-library" menu.
|
yann@2384
|
194 |
|
yann@2384
|
195 |
--------------------------------
|
yann@2565
|
196 |
Symptoms:
|
yann@2565
|
197 |
glibc start files and headers fail with: [/usr/include/limits.h] Error 1
|
yann@2565
|
198 |
|
yann@2565
|
199 |
Explanations:
|
yann@2674
|
200 |
Old glibc (and eglibc) Makefiles break with make-3.82.
|
yann@2565
|
201 |
|
yann@2565
|
202 |
Status:
|
yann@2565
|
203 |
CURRENT
|
yann@2565
|
204 |
|
yann@2565
|
205 |
Fix:
|
yann@2674
|
206 |
None so far. It would require some glibc/eglibc hacking.
|
yann@2565
|
207 |
|
yann@2565
|
208 |
Workaround:
|
yann@2565
|
209 |
There two possible workarounds:
|
yann@2674
|
210 |
1- ask crosstool-NG to build make-3.81 just for this build session:
|
yann@2674
|
211 |
Select the following options:
|
yann@2674
|
212 |
Paths and misc options --->
|
yann@2674
|
213 |
[*] Try features marked as EXPERIMENTAL
|
yann@2674
|
214 |
Companion tools --->
|
yann@2674
|
215 |
[*] Build some companion tools
|
yann@2674
|
216 |
[*] make
|
yann@2565
|
217 |
2- manually install make-3.81 to take precedence over the system make.
|
yann@2565
|
218 |
|
yann@2565
|
219 |
--------------------------------
|
yann@2674
|
220 |
Symptoms:
|
yann@2674
|
221 |
The build fails with "mixed implicit and normal rules. Stop."
|
yann@2674
|
222 |
|
yann@2674
|
223 |
Explanations:
|
yann@2674
|
224 |
Old glibc (and eglibc) Makefiles break with make-3.82.
|
yann@2674
|
225 |
|
yann@2674
|
226 |
Status:
|
yann@2674
|
227 |
CURRENT
|
yann@2674
|
228 |
|
yann@2674
|
229 |
Fix:
|
yann@2674
|
230 |
None so far. See above issue.
|
yann@2674
|
231 |
|
yann@2674
|
232 |
Workaround:
|
yann@2674
|
233 |
See above issue.
|
yann@2674
|
234 |
|
yann@2674
|
235 |
--------------------------------
|
js@2882
|
236 |
Symptoms:
|
js@2882
|
237 |
On x86_64 hosts with 32bit userspace the GMP build fails with:
|
js@2882
|
238 |
configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
|
js@2882
|
239 |
in this configuration expects 64 bits.
|
js@2882
|
240 |
You appear to have set $CFLAGS, perhaps you also need to tell GMP the
|
js@2882
|
241 |
intended ABI, see "ABI and ISA" in the manual.
|
js@2882
|
242 |
|
js@2882
|
243 |
Explanations:
|
js@2882
|
244 |
"uname -m" detects x86_64 but the build host is really x86.
|
js@2882
|
245 |
|
js@2882
|
246 |
Status:
|
js@2882
|
247 |
CURRENT
|
js@2882
|
248 |
|
js@2882
|
249 |
Fix:
|
js@2882
|
250 |
None so far. See above issue.
|
js@2882
|
251 |
|
js@2882
|
252 |
Workaround:
|
js@2882
|
253 |
use "setarch i686 ct-ng build"
|
js@2882
|
254 |
|
js@2882
|
255 |
--------------------------------
|