debug/gdb: fix for psim build failure due to -lz in gdb-7.2.
Signed-off-by: "Horst Kronstorfer" <horst.kronstorfer@aon.at>
[yann.morin.1998@anciens.enib.fr: fix space-damage]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 78286fe70b62cee395bc603a5e44ef136c4531e3)
1 File.........: B - Known issues.txt
2 Copyrigth....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
3 License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
10 This files lists the known issues encountered while developping crosstool-NG,
11 but that could not be addressed before the release.
13 The file has one section for each known issue, each section containing four
14 sub-sections: Symptoms, Explanations, Fix, and Workaround.
16 Each section is separated from the others with a lines of at least 4 dashes.
18 The following dummy section explains it all.
20 --------------------------------
22 A one-liner of what you would observe.
25 An as much as possible in-depth explanations of the context, why it
26 happens, what has been investigated so far, and possible orientations
27 as how to try to solve this (eg. URLs, code snippets...).
30 What you have to do to fix it, if at all possible.
31 The fact that there is a fix, and yet this is a known issue means that
32 time to incorporate the fix in crosstool-NG was missing, or planned for
36 What you can do to fix it *temporarily*, if at all possible.
37 A workaround is not a real fix, as it can break other parts of
38 crosstool-NG, but at least makes you going in your particular case.
40 So now, on for the real issues...
42 --------------------------------
44 gcc is not found, although I *do* have gcc installed.
47 This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
48 Because crosstool-NG create links to gcc for the build and host environment,
49 those symlinks are in fact pointing to ccache, which then doesn't know how
52 A possible fix could probably set the environment variable CCACHE_CC to the
61 --------------------------------
63 The extract and/or path steps fail under Cygwin.
66 This is not related to crosstool-NG. Mounts under Cygwin are by default not
67 case-sensitive. You have to use so-called "managed" mounts. See:
68 http://cygwin.com/faq.html section 4, question 32.
71 Use "managed" mounts for the directories where you build *and* install your
77 --------------------------------
79 uClibc fails to build under Cygwin.
82 With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
83 not (currently) possible to build this cross-ldd under Cygwin.
89 Disable the cross-ldd build.
91 --------------------------------
93 On 64-bit build systems, the glibc (possibly eglibc too) build fails for
94 64-bit targets, because it can not find libgcc.
97 This issue has been observed when the companion libraries are built
98 statically. For an unknown reason, in this case, the libgcc built by the
99 core gcc is not located in the same place it is located when building
100 with shared companion libraries.
106 Build shared companion libraries.
108 --------------------------------
110 While building the final gcc, I get an error message that ends with:
111 libtool.m4: error: problem compiling FC test program
114 The gcc build procedure tries to run a Fortran test to see if it has a
115 working native fortran compiler installed on the build machine, and it
116 can't find one. A native Fortran compiler is needed (seems to be neede)
117 to build the Fortran frontend of the cross-compiler.
118 Even if you don't want to build the Fortran frontend, gcc tries to see
119 if it has one, but fails. This is no problem, as the Fortran frontend
120 will not be built. There is nothing to be worry about (unless you do
121 want to build the Fortran frontend, of course).
124 None so far. It's a spurious error, so there will probably never be
125 a fix for this issue.
128 None needed, it's a spurious error.
130 --------------------------------
132 gcc barfs because it is "unable to detect the exception model".
135 On some architectures, proper stack unwinding (C++) requires that
136 setjmp/longjmp (sjlj) be used, while on other architectures do not
137 need sjlj. On some architectures, gcc is unable to determine whether
138 sjlj are needed or not.
144 Trying setting use of sjlj to either 'Y' or 'N' (instead of the
145 default 'M') in the menuconfig, option CT_CC_GCC_SJLJ_EXCEPTIONS
146 labelled "Use sjlj for exceptions".
148 --------------------------------