|
yann@771
|
1 |
This files lists the known issues encountered while developping crosstool-NG,
|
|
yann@771
|
2 |
but that could not be addressed before the release.
|
|
yann@771
|
3 |
|
|
yann@771
|
4 |
The file has one section for each known issue, each section containing four
|
|
yann@771
|
5 |
sub-sections: Symptoms, Explanations, Fix, and Workaround.
|
|
yann@771
|
6 |
|
|
yann@771
|
7 |
Each section is separated from the others with a lines of at least 4 dashes.
|
|
yann@771
|
8 |
|
|
yann@771
|
9 |
The following dummy section explains it all.
|
|
yann@771
|
10 |
|
|
yann@771
|
11 |
--------------------------------
|
|
yann@771
|
12 |
Symptoms:
|
|
yann@771
|
13 |
A one-liner of what you would observe.
|
|
yann@771
|
14 |
|
|
yann@771
|
15 |
Explanations:
|
|
yann@771
|
16 |
An as much as possible in-depth explanations of the context, why it
|
|
yann@771
|
17 |
happens, what has been investigated so far, and possible orientations
|
|
yann@771
|
18 |
as how to try to solve this (eg. URLs, code snippets...).
|
|
yann@771
|
19 |
|
|
yann@771
|
20 |
Fix:
|
|
yann@771
|
21 |
What you have to do to fix it, if at all possible.
|
|
yann@771
|
22 |
The fact that there is a fix, and yet this is a known issue means that
|
|
yann@771
|
23 |
time to incorporate the fix in crosstool-NG was missing, or planned for
|
|
yann@771
|
24 |
a future release.
|
|
yann@771
|
25 |
|
|
yann@771
|
26 |
Workaround:
|
|
yann@771
|
27 |
What you can do to fix it *temporarily*, if at all possible.
|
|
yann@771
|
28 |
A workaround is not a real fix, as it can break other parts of
|
|
yann@771
|
29 |
crosstool-NG, but at least makes you going in your particular case.
|
|
yann@771
|
30 |
|
|
yann@771
|
31 |
So now, on for the real issues...
|
|
yann@771
|
32 |
|
|
yann@771
|
33 |
--------------------------------
|
|
yann@771
|
34 |
Symptoms:
|
|
yann@771
|
35 |
Seemingly native toolchains do not build.
|
|
yann@771
|
36 |
|
|
yann@771
|
37 |
Explanations:
|
|
yann@771
|
38 |
Seemingly native toolchains are toolchains that target the same architecture
|
|
yann@771
|
39 |
as the one it is built on, and on which it will run, but the machine tuple
|
|
yann@771
|
40 |
may be different (eg i686 vs. i386, or x86_64-unknown-linux-gnu vs.
|
|
yann@771
|
41 |
x86_64-pc-linux-gnu).
|
|
yann@771
|
42 |
|
|
yann@771
|
43 |
This seems to happen when building glibc-2.7 based toolchains only, for
|
|
yann@771
|
44 |
x86 and for x86_64.
|
|
yann@771
|
45 |
|
|
yann@771
|
46 |
Only the system part of the tuple (here, linux-gnu) needs to be the same to
|
|
yann@885
|
47 |
trigger the bug. Which means that building a tolchain for either x86 or
|
|
yann@885
|
48 |
x86_64 on either x86 or x86_64 breaks.
|
|
yann@771
|
49 |
|
|
yann@771
|
50 |
Fix:
|
|
yann@771
|
51 |
None known.
|
|
yann@771
|
52 |
|
|
yann@771
|
53 |
Workaround:
|
|
yann@771
|
54 |
If this happens for you, stick with glibc-2.6.1 for now.
|
|
yann@771
|
55 |
Or investigate! :-)
|
|
yann@771
|
56 |
|
|
yann@771
|
57 |
--------------------------------
|
|
yann@885
|
58 |
Symptoms:
|
|
yann@885
|
59 |
gcc is not found, although I *do* have gcc installed.
|
|
yann@885
|
60 |
|
|
yann@885
|
61 |
Explanations:
|
|
yann@885
|
62 |
This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
|
|
yann@885
|
63 |
Because crosstool-NG create links to gcc for the build and host environment,
|
|
yann@885
|
64 |
those symlinks are in fact pointing to ccache, which then doesn't know how
|
|
yann@885
|
65 |
to run the compiler.
|
|
yann@885
|
66 |
|
|
yann@885
|
67 |
A possible fix could probably set the environment variable CCACHE_CC to the
|
|
yann@885
|
68 |
actual compiler used.
|
|
yann@885
|
69 |
|
|
yann@885
|
70 |
Fix:
|
|
yann@885
|
71 |
None known.
|
|
yann@885
|
72 |
|
|
yann@885
|
73 |
Workaround:
|
|
yann@885
|
74 |
Uninstall ccache.
|
|
yann@885
|
75 |
|
|
yann@885
|
76 |
--------------------------------
|