binutils/binutils: do not fwd declare struct stat (2.22).
For canadian cross to host i686-mingw32 fwd declaring
struct stat is not possible.
Instead #include <sys/stat.h>
Signed-off-by: Titus von Boxberg <titus@v9g.de>
Message-Id: <417a15d4277913841ddd.1353100974@tschetwerikow.boxberg.lan>
Patchwork-Id: 199733
1 File.........: B - Known issues.txt
2 Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@free.fr>
3 License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
10 This files lists the known issues encountered while developing 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- or two-liner of what you would observe.
23 Usually, the error message you would see in the build logs.
26 An as much as possible in-depth explanations of the context, why it
27 happens, what has been investigated so far, and possible orientations
28 as how to try to solve this (eg. URLs, code snippets...).
31 Tells about the status of the issue:
32 UNCONFIRMED : missing information, or unable, to reproduce, but there
33 is consensus that there is an issue somewhere...
34 CURRENT : the issue is applicable.
35 DEPRECATED : the issue used to apply in some cases, but has not been
36 confirmed or reported again lately.
37 CLOSED : the issue is no longer valid, and a fix has been added
38 either as a patch to this component, and/or as a
39 workaround in the scripts and/or the configuration.
42 What you have to do to fix it, if at all possible.
43 The fact that there is a fix, and yet this is a known issue means that
44 time to incorporate the fix in crosstool-NG was missing, or planned for
48 What you can do to fix it *temporarily*, if at all possible.
49 A workaround is not a real fix, as it can break other parts of
50 crosstool-NG, but at least makes you going in your particular case.
52 So now, on for the real issues...
54 --------------------------------
56 gcc is not found, although I *do* have gcc installed.
59 This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
60 Because crosstool-NG create links to gcc for the build and host environment,
61 those symlinks are in fact pointing to ccache, which then doesn't know how
64 A possible fix could probably set the environment variable CCACHE_CC to the
76 --------------------------------
78 The extract and/or path steps fail under Cygwin.
81 This is not related to crosstool-NG. Mounts under Cygwin are by default not
82 case-sensitive. You have to use so-called "managed" mounts. See:
83 http://cygwin.com/faq.html section 4, question 32.
89 Use "managed" mounts for the directories where you build *and* install your
95 --------------------------------
97 uClibc fails to build under Cygwin.
100 With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
101 not (currently) possible to build this cross-ldd under Cygwin.
110 Disable the cross-ldd build.
112 --------------------------------
114 On 64-bit build systems, the glibc (possibly eglibc too) build fails for
115 64-bit targets, because it can not find libgcc.
118 This issue has been observed when the companion libraries are built
119 statically. For an unknown reason, in this case, the libgcc built by the
120 core gcc is not located in the same place it is located when building
121 with shared companion libraries.
130 Build shared companion libraries.
132 --------------------------------
134 libtool.m4: error: problem compiling FC test program
137 The gcc build procedure tries to run a Fortran test to see if it has a
138 working native fortran compiler installed on the build machine, and it
139 can't find one. A native Fortran compiler is needed (seems to be needed)
140 to build the Fortran frontend of the cross-compiler.
141 Even if you don't want to build the Fortran frontend, gcc tries to see
142 if it has one, but fails. This is no problem, as the Fortran frontend
143 will not be built. There is nothing to be worry about (unless you do
144 want to build the Fortran frontend, of course).
150 None so far. It's a spurious error, so there will probably never be
151 a fix for this issue.
154 None needed, it's a spurious error.
156 --------------------------------
158 unable to detect the exception model
161 On some architectures, proper stack unwinding (C++) requires that
162 setjmp/longjmp (sjlj) be used, while on other architectures do not
163 need sjlj. On some architectures, gcc is unable to determine whether
164 sjlj are needed or not.
173 Trying setting use of sjlj to either 'Y' or 'N' (instead of the
174 default 'M') in the menuconfig, option CT_CC_GCC_SJLJ_EXCEPTIONS
175 labelled "Use sjlj for exceptions".
177 --------------------------------
179 configure: error: forced unwind support is required
182 The issue seems to be related to building NPTL on old versions
183 of glibc (and possibly eglibc as well) on some architectures
184 (seen on powerpc, s390, s390x and x86_64).
190 None so far. It would require some glibc hacking.
193 Try setting "Force unwind support" in the "C-library" menu.
195 --------------------------------
197 glibc start files and headers fail with: [/usr/include/limits.h] Error 1
200 Old glibc (and eglibc) Makefiles break with make-3.82.
206 None so far. It would require some glibc/eglibc hacking.
209 There two possible workarounds:
210 1- ask crosstool-NG to build make-3.81 just for this build session:
211 Select the following options:
212 Paths and misc options --->
213 [*] Try features marked as EXPERIMENTAL
215 [*] Build some companion tools
217 2- manually install make-3.81 to take precedence over the system make.
219 --------------------------------
221 The build fails with "mixed implicit and normal rules. Stop."
224 Old glibc (and eglibc) Makefiles break with make-3.82.
230 None so far. See above issue.
235 --------------------------------
237 On x86_64 hosts with 32bit userspace the GMP build fails with:
238 configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
239 in this configuration expects 64 bits.
240 You appear to have set $CFLAGS, perhaps you also need to tell GMP the
241 intended ABI, see "ABI and ISA" in the manual.
244 "uname -m" detects x86_64 but the build host is really x86.
250 None so far. See above issue.
253 use "setarch i686 ct-ng build"
255 --------------------------------