1 | This is Info file gcc.info, produced by Makeinfo-1.55 from the input |
---|
2 | file gcc.texi. |
---|
3 | |
---|
4 | This file documents the use and the internals of the GNU compiler. |
---|
5 | |
---|
6 | Published by the Free Software Foundation 59 Temple Place - Suite 330 |
---|
7 | Boston, MA 02111-1307 USA |
---|
8 | |
---|
9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software |
---|
10 | Foundation, Inc. |
---|
11 | |
---|
12 | Permission is granted to make and distribute verbatim copies of this |
---|
13 | manual provided the copyright notice and this permission notice are |
---|
14 | preserved on all copies. |
---|
15 | |
---|
16 | Permission is granted to copy and distribute modified versions of |
---|
17 | this manual under the conditions for verbatim copying, provided also |
---|
18 | that the sections entitled "GNU General Public License," "Funding for |
---|
19 | Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are |
---|
20 | included exactly as in the original, and provided that the entire |
---|
21 | resulting derived work is distributed under the terms of a permission |
---|
22 | notice identical to this one. |
---|
23 | |
---|
24 | Permission is granted to copy and distribute translations of this |
---|
25 | manual into another language, under the above conditions for modified |
---|
26 | versions, except that the sections entitled "GNU General Public |
---|
27 | License," "Funding for Free Software," and "Protect Your Freedom--Fight |
---|
28 | `Look And Feel'", and this permission notice, may be included in |
---|
29 | translations approved by the Free Software Foundation instead of in the |
---|
30 | original English. |
---|
31 | |
---|
32 | |
---|
33 | File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble |
---|
34 | |
---|
35 | Installation Problems |
---|
36 | ===================== |
---|
37 | |
---|
38 | This is a list of problems (and some apparent problems which don't |
---|
39 | really mean anything is wrong) that show up during installation of GNU |
---|
40 | CC. |
---|
41 | |
---|
42 | * On certain systems, defining certain environment variables such as |
---|
43 | `CC' can interfere with the functioning of `make'. |
---|
44 | |
---|
45 | * If you encounter seemingly strange errors when trying to build the |
---|
46 | compiler in a directory other than the source directory, it could |
---|
47 | be because you have previously configured the compiler in the |
---|
48 | source directory. Make sure you have done all the necessary |
---|
49 | preparations. *Note Other Dir::. |
---|
50 | |
---|
51 | * If you build GNU CC on a BSD system using a directory stored in a |
---|
52 | System V file system, problems may occur in running `fixincludes' |
---|
53 | if the System V file system doesn't support symbolic links. These |
---|
54 | problems result in a failure to fix the declaration of `size_t' in |
---|
55 | `sys/types.h'. If you find that `size_t' is a signed type and |
---|
56 | that type mismatches occur, this could be the cause. |
---|
57 | |
---|
58 | The solution is not to use such a directory for building GNU CC. |
---|
59 | |
---|
60 | * In previous versions of GNU CC, the `gcc' driver program looked for |
---|
61 | `as' and `ld' in various places; for example, in files beginning |
---|
62 | with `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in |
---|
63 | the directory `/usr/local/lib/gcc-lib/TARGET/VERSION'. |
---|
64 | |
---|
65 | Thus, to use a version of `as' or `ld' that is not the system |
---|
66 | default, for example `gas' or GNU `ld', you must put them in that |
---|
67 | directory (or make links to them from that directory). |
---|
68 | |
---|
69 | * Some commands executed when making the compiler may fail (return a |
---|
70 | non-zero status) and be ignored by `make'. These failures, which |
---|
71 | are often due to files that were not found, are expected, and can |
---|
72 | safely be ignored. |
---|
73 | |
---|
74 | * It is normal to have warnings in compiling certain files about |
---|
75 | unreachable code and about enumeration type clashes. These files' |
---|
76 | names begin with `insn-'. Also, `real.c' may get some warnings |
---|
77 | that you can ignore. |
---|
78 | |
---|
79 | * Sometimes `make' recompiles parts of the compiler when installing |
---|
80 | the compiler. In one case, this was traced down to a bug in |
---|
81 | `make'. Either ignore the problem or switch to GNU Make. |
---|
82 | |
---|
83 | * If you have installed a program known as purify, you may find that |
---|
84 | it causes errors while linking `enquire', which is part of building |
---|
85 | GNU CC. The fix is to get rid of the file `real-ld' which purify |
---|
86 | installs--so that GNU CC won't try to use it. |
---|
87 | |
---|
88 | * On SLS 1.01, a Linux-based GNU system, there is a problem with |
---|
89 | `libc.a': it does not contain the obstack functions. However, GNU |
---|
90 | CC assumes that the obstack functions are in `libc.a' when it is |
---|
91 | the GNU C library. To work around this problem, change the |
---|
92 | `__GNU_LIBRARY__' conditional around line 31 to `#if 1'. |
---|
93 | |
---|
94 | * On some 386 systems, building the compiler never finishes because |
---|
95 | `enquire' hangs due to a hardware problem in the motherboard--it |
---|
96 | reports floating point exceptions to the kernel incorrectly. You |
---|
97 | can install GNU CC except for `float.h' by patching out the |
---|
98 | command to run `enquire'. You may also be able to fix the problem |
---|
99 | for real by getting a replacement motherboard. This problem was |
---|
100 | observed in Revision E of the Micronics motherboard, and is fixed |
---|
101 | in Revision F. It has also been observed in the MYLEX MXA-33 |
---|
102 | motherboard. |
---|
103 | |
---|
104 | If you encounter this problem, you may also want to consider |
---|
105 | removing the FPU from the socket during the compilation. |
---|
106 | Alternatively, if you are running SCO Unix, you can reboot and |
---|
107 | force the FPU to be ignored. To do this, type `hd(40)unix auto |
---|
108 | ignorefpu'. |
---|
109 | |
---|
110 | * On some 386 systems, GNU CC crashes trying to compile `enquire.c'. |
---|
111 | This happens on machines that don't have a 387 FPU chip. On 386 |
---|
112 | machines, the system kernel is supposed to emulate the 387 when you |
---|
113 | don't have one. The crash is due to a bug in the emulator. |
---|
114 | |
---|
115 | One of these systems is the Unix from Interactive Systems: 386/ix. |
---|
116 | On this system, an alternate emulator is provided, and it does |
---|
117 | work. To use it, execute this command as super-user: |
---|
118 | |
---|
119 | ln /etc/emulator.rel1 /etc/emulator |
---|
120 | |
---|
121 | and then reboot the system. (The default emulator file remains |
---|
122 | present under the name `emulator.dflt'.) |
---|
123 | |
---|
124 | Try using `/etc/emulator.att', if you have such a problem on the |
---|
125 | SCO system. |
---|
126 | |
---|
127 | Another system which has this problem is Esix. We don't know |
---|
128 | whether it has an alternate emulator that works. |
---|
129 | |
---|
130 | On NetBSD 0.8, a similar problem manifests itself as these error |
---|
131 | messages: |
---|
132 | |
---|
133 | enquire.c: In function `fprop': |
---|
134 | enquire.c:2328: floating overflow |
---|
135 | |
---|
136 | * On SCO systems, when compiling GNU CC with the system's compiler, |
---|
137 | do not use `-O'. Some versions of the system's compiler miscompile |
---|
138 | GNU CC with `-O'. |
---|
139 | |
---|
140 | * Sometimes on a Sun 4 you may observe a crash in the program |
---|
141 | `genflags' or `genoutput' while building GNU CC. This is said to |
---|
142 | be due to a bug in `sh'. You can probably get around it by running |
---|
143 | `genflags' or `genoutput' manually and then retrying the `make'. |
---|
144 | |
---|
145 | * On Solaris 2, executables of GNU CC version 2.0.2 are commonly |
---|
146 | available, but they have a bug that shows up when compiling current |
---|
147 | versions of GNU CC: undefined symbol errors occur during assembly |
---|
148 | if you use `-g'. |
---|
149 | |
---|
150 | The solution is to compile the current version of GNU CC without |
---|
151 | `-g'. That makes a working compiler which you can use to recompile |
---|
152 | with `-g'. |
---|
153 | |
---|
154 | * Solaris 2 comes with a number of optional OS packages. Some of |
---|
155 | these packages are needed to use GNU CC fully. If you did not |
---|
156 | install all optional packages when installing Solaris, you will |
---|
157 | need to verify that the packages that GNU CC needs are installed. |
---|
158 | |
---|
159 | To check whether an optional package is installed, use the |
---|
160 | `pkginfo' command. To add an optional package, use the `pkgadd' |
---|
161 | command. For further details, see the Solaris documentation. |
---|
162 | |
---|
163 | For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc', |
---|
164 | `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'. |
---|
165 | |
---|
166 | For Solaris 2.2, GNU CC needs an additional seventh package: |
---|
167 | `SUNWsprot'. |
---|
168 | |
---|
169 | * On Solaris 2, trying to use the linker and other tools in |
---|
170 | `/usr/ucb' to install GNU CC has been observed to cause trouble. |
---|
171 | For example, the linker may hang indefinitely. The fix is to |
---|
172 | remove `/usr/ucb' from your `PATH'. |
---|
173 | |
---|
174 | * If you use the 1.31 version of the MIPS assembler (such as was |
---|
175 | shipped with Ultrix 3.1), you will need to use the |
---|
176 | -fno-delayed-branch switch when optimizing floating point code. |
---|
177 | Otherwise, the assembler will complain when the GCC compiler fills |
---|
178 | a branch delay slot with a floating point instruction, such as |
---|
179 | `add.d'. |
---|
180 | |
---|
181 | * If on a MIPS system you get an error message saying "does not have |
---|
182 | gp sections for all it's [sic] sectons [sic]", don't worry about |
---|
183 | it. This happens whenever you use GAS with the MIPS linker, but |
---|
184 | there is not really anything wrong, and it is okay to use the |
---|
185 | output file. You can stop such warnings by installing the GNU |
---|
186 | linker. |
---|
187 | |
---|
188 | It would be nice to extend GAS to produce the gp tables, but they |
---|
189 | are optional, and there should not be a warning about their |
---|
190 | absence. |
---|
191 | |
---|
192 | * In Ultrix 4.0 on the MIPS machine, `stdio.h' does not work with GNU |
---|
193 | CC at all unless it has been fixed with `fixincludes'. This causes |
---|
194 | problems in building GNU CC. Once GNU CC is installed, the |
---|
195 | problems go away. |
---|
196 | |
---|
197 | To work around this problem, when making the stage 1 compiler, |
---|
198 | specify this option to Make: |
---|
199 | |
---|
200 | GCC_FOR_TARGET="./xgcc -B./ -I./include" |
---|
201 | |
---|
202 | When making stage 2 and stage 3, specify this option: |
---|
203 | |
---|
204 | CFLAGS="-g -I./include" |
---|
205 | |
---|
206 | * Users have reported some problems with version 2.0 of the MIPS |
---|
207 | compiler tools that were shipped with Ultrix 4.1. Version 2.10 |
---|
208 | which came with Ultrix 4.2 seems to work fine. |
---|
209 | |
---|
210 | Users have also reported some problems with version 2.20 of the |
---|
211 | MIPS compiler tools that were shipped with RISC/os 4.x. The |
---|
212 | earlier version 2.11 seems to work fine. |
---|
213 | |
---|
214 | * Some versions of the MIPS linker will issue an assertion failure |
---|
215 | when linking code that uses `alloca' against shared libraries on |
---|
216 | RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug in the |
---|
217 | linker, that is supposed to be fixed in future revisions. To |
---|
218 | protect against this, GNU CC passes `-non_shared' to the linker |
---|
219 | unless you pass an explicit `-shared' or `-call_shared' switch. |
---|
220 | |
---|
221 | * On System V release 3, you may get this error message while |
---|
222 | linking: |
---|
223 | |
---|
224 | ld fatal: failed to write symbol name SOMETHING |
---|
225 | in strings table for file WHATEVER |
---|
226 | |
---|
227 | This probably indicates that the disk is full or your ULIMIT won't |
---|
228 | allow the file to be as large as it needs to be. |
---|
229 | |
---|
230 | This problem can also result because the kernel parameter `MAXUMEM' |
---|
231 | is too small. If so, you must regenerate the kernel and make the |
---|
232 | value much larger. The default value is reported to be 1024; a |
---|
233 | value of 32768 is said to work. Smaller values may also work. |
---|
234 | |
---|
235 | * On System V, if you get an error like this, |
---|
236 | |
---|
237 | /usr/local/lib/bison.simple: In function `yyparse': |
---|
238 | /usr/local/lib/bison.simple:625: virtual memory exhausted |
---|
239 | |
---|
240 | that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'. |
---|
241 | |
---|
242 | * Current GNU CC versions probably do not work on version 2 of the |
---|
243 | NeXT operating system. |
---|
244 | |
---|
245 | * On NeXTStep 3.0, the Objective C compiler does not work, due, |
---|
246 | apparently, to a kernel bug that it happens to trigger. This |
---|
247 | problem does not happen on 3.1. |
---|
248 | |
---|
249 | * On the Tower models 4N0 and 6N0, by default a process is not |
---|
250 | allowed to have more than one megabyte of memory. GNU CC cannot |
---|
251 | compile itself (or many other programs) with `-O' in that much |
---|
252 | memory. |
---|
253 | |
---|
254 | To solve this problem, reconfigure the kernel adding the following |
---|
255 | line to the configuration file: |
---|
256 | |
---|
257 | MAXUMEM = 4096 |
---|
258 | |
---|
259 | * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a |
---|
260 | bug in the assembler that must be fixed before GNU CC can be |
---|
261 | built. This bug manifests itself during the first stage of |
---|
262 | compilation, while building `libgcc2.a': |
---|
263 | |
---|
264 | _floatdisf |
---|
265 | cc1: warning: `-g' option not supported on this version of GCC |
---|
266 | cc1: warning: `-g1' option not supported on this version of GCC |
---|
267 | ./xgcc: Internal compiler error: program as got fatal signal 11 |
---|
268 | |
---|
269 | A patched version of the assembler is available by anonymous ftp |
---|
270 | from `altdorf.ai.mit.edu' as the file |
---|
271 | `archive/cph/hpux-8.0-assembler'. If you have HP software support, |
---|
272 | the patch can also be obtained directly from HP, as described in |
---|
273 | the following note: |
---|
274 | |
---|
275 | This is the patched assembler, to patch SR#1653-010439, where |
---|
276 | the assembler aborts on floating point constants. |
---|
277 | |
---|
278 | The bug is not really in the assembler, but in the shared |
---|
279 | library version of the function "cvtnum(3c)". The bug on |
---|
280 | "cvtnum(3c)" is SR#4701-078451. Anyway, the attached |
---|
281 | assembler uses the archive library version of "cvtnum(3c)" |
---|
282 | and thus does not exhibit the bug. |
---|
283 | |
---|
284 | This patch is also known as PHCO_4484. |
---|
285 | |
---|
286 | * On HP-UX version 8.05, but not on 8.07 or more recent versions, |
---|
287 | the `fixproto' shell script triggers a bug in the system shell. |
---|
288 | If you encounter this problem, upgrade your operating system or |
---|
289 | use BASH (the GNU shell) to run `fixproto'. |
---|
290 | |
---|
291 | * Some versions of the Pyramid C compiler are reported to be unable |
---|
292 | to compile GNU CC. You must use an older version of GNU CC for |
---|
293 | bootstrapping. One indication of this problem is if you get a |
---|
294 | crash when GNU CC compiles the function `muldi3' in file |
---|
295 | `libgcc2.c'. |
---|
296 | |
---|
297 | You may be able to succeed by getting GNU CC version 1, installing |
---|
298 | it, and using it to compile GNU CC version 2. The bug in the |
---|
299 | Pyramid C compiler does not seem to affect GNU CC version 1. |
---|
300 | |
---|
301 | * There may be similar problems on System V Release 3.1 on 386 |
---|
302 | systems. |
---|
303 | |
---|
304 | * On the Intel Paragon (an i860 machine), if you are using operating |
---|
305 | system version 1.0, you will get warnings or errors about |
---|
306 | redefinition of `va_arg' when you build GNU CC. |
---|
307 | |
---|
308 | If this happens, then you need to link most programs with the |
---|
309 | library `iclib.a'. You must also modify `stdio.h' as follows: |
---|
310 | before the lines |
---|
311 | |
---|
312 | #if defined(__i860__) && !defined(_VA_LIST) |
---|
313 | #include <va_list.h> |
---|
314 | |
---|
315 | insert the line |
---|
316 | |
---|
317 | #if __PGC__ |
---|
318 | |
---|
319 | and after the lines |
---|
320 | |
---|
321 | extern int vprintf(const char *, va_list ); |
---|
322 | extern int vsprintf(char *, const char *, va_list ); |
---|
323 | #endif |
---|
324 | |
---|
325 | insert the line |
---|
326 | |
---|
327 | #endif /* __PGC__ */ |
---|
328 | |
---|
329 | These problems don't exist in operating system version 1.1. |
---|
330 | |
---|
331 | * On the Altos 3068, programs compiled with GNU CC won't work unless |
---|
332 | you fix a kernel bug. This happens using system versions V.2.2 |
---|
333 | 1.0gT1 and V.2.2 1.0e and perhaps later versions as well. See the |
---|
334 | file `README.ALTOS'. |
---|
335 | |
---|
336 | * You will get several sorts of compilation and linking errors on the |
---|
337 | we32k if you don't follow the special instructions. *Note |
---|
338 | Configurations::. |
---|
339 | |
---|
340 | * A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto |
---|
341 | program to report an error of the form: |
---|
342 | |
---|
343 | ./fixproto: sh internal 1K buffer overflow |
---|
344 | |
---|
345 | To fix this, change the first line of the fixproto script to look |
---|
346 | like: |
---|
347 | |
---|
348 | #!/bin/ksh |
---|
349 | |
---|
350 | |
---|
351 | File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble |
---|
352 | |
---|
353 | Cross-Compiler Problems |
---|
354 | ======================= |
---|
355 | |
---|
356 | You may run into problems with cross compilation on certain machines, |
---|
357 | for several reasons. |
---|
358 | |
---|
359 | * Cross compilation can run into trouble for certain machines because |
---|
360 | some target machines' assemblers require floating point numbers to |
---|
361 | be written as *integer* constants in certain contexts. |
---|
362 | |
---|
363 | The compiler writes these integer constants by examining the |
---|
364 | floating point value as an integer and printing that integer, |
---|
365 | because this is simple to write and independent of the details of |
---|
366 | the floating point representation. But this does not work if the |
---|
367 | compiler is running on a different machine with an incompatible |
---|
368 | floating point format, or even a different byte-ordering. |
---|
369 | |
---|
370 | In addition, correct constant folding of floating point values |
---|
371 | requires representing them in the target machine's format. (The C |
---|
372 | standard does not quite require this, but in practice it is the |
---|
373 | only way to win.) |
---|
374 | |
---|
375 | It is now possible to overcome these problems by defining macros |
---|
376 | such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of |
---|
377 | work for each target machine. *Note Cross-compilation::. |
---|
378 | |
---|
379 | * At present, the program `mips-tfile' which adds debug support to |
---|
380 | object files on MIPS systems does not work in a cross compile |
---|
381 | environment. |
---|
382 | |
---|
383 | |
---|
384 | File: gcc.info, Node: Interoperation, Next: External Bugs, Prev: Cross-Compiler Problems, Up: Trouble |
---|
385 | |
---|
386 | Interoperation |
---|
387 | ============== |
---|
388 | |
---|
389 | This section lists various difficulties encountered in using GNU C or |
---|
390 | GNU C++ together with other compilers or with the assemblers, linkers, |
---|
391 | libraries and debuggers on certain systems. |
---|
392 | |
---|
393 | * Objective C does not work on the RS/6000. |
---|
394 | |
---|
395 | * GNU C++ does not do name mangling in the same way as other C++ |
---|
396 | compilers. This means that object files compiled with one compiler |
---|
397 | cannot be used with another. |
---|
398 | |
---|
399 | This effect is intentional, to protect you from more subtle |
---|
400 | problems. Compilers differ as to many internal details of C++ |
---|
401 | implementation, including: how class instances are laid out, how |
---|
402 | multiple inheritance is implemented, and how virtual function |
---|
403 | calls are handled. If the name encoding were made the same, your |
---|
404 | programs would link against libraries provided from other |
---|
405 | compilers--but the programs would then crash when run. |
---|
406 | Incompatible libraries are then detected at link time, rather than |
---|
407 | at run time. |
---|
408 | |
---|
409 | * Older GDB versions sometimes fail to read the output of GNU CC |
---|
410 | version 2. If you have trouble, get GDB version 4.4 or later. |
---|
411 | |
---|
412 | * DBX rejects some files produced by GNU CC, though it accepts |
---|
413 | similar constructs in output from PCC. Until someone can supply a |
---|
414 | coherent description of what is valid DBX input and what is not, |
---|
415 | there is nothing I can do about these problems. You are on your |
---|
416 | own. |
---|
417 | |
---|
418 | * The GNU assembler (GAS) does not support PIC. To generate PIC |
---|
419 | code, you must use some other assembler, such as `/bin/as'. |
---|
420 | |
---|
421 | * On some BSD systems, including some versions of Ultrix, use of |
---|
422 | profiling causes static variable destructors (currently used only |
---|
423 | in C++) not to be run. |
---|
424 | |
---|
425 | * Use of `-I/usr/include' may cause trouble. |
---|
426 | |
---|
427 | Many systems come with header files that won't work with GNU CC |
---|
428 | unless corrected by `fixincludes'. The corrected header files go |
---|
429 | in a new directory; GNU CC searches this directory before |
---|
430 | `/usr/include'. If you use `-I/usr/include', this tells GNU CC to |
---|
431 | search `/usr/include' earlier on, before the corrected headers. |
---|
432 | The result is that you get the uncorrected header files. |
---|
433 | |
---|
434 | Instead, you should use these options (when compiling C programs): |
---|
435 | |
---|
436 | -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include |
---|
437 | |
---|
438 | For C++ programs, GNU CC also uses a special directory that |
---|
439 | defines C++ interfaces to standard C subroutines. This directory |
---|
440 | is meant to be searched *before* other standard include |
---|
441 | directories, so that it takes precedence. If you are compiling |
---|
442 | C++ programs and specifying include directories explicitly, use |
---|
443 | this option first, then the two options above: |
---|
444 | |
---|
445 | -I/usr/local/lib/g++-include |
---|
446 | |
---|
447 | * On some SGI systems, when you use `-lgl_s' as an option, it gets |
---|
448 | translated magically to `-lgl_s -lX11_s -lc_s'. Naturally, this |
---|
449 | does not happen when you use GNU CC. You must specify all three |
---|
450 | options explicitly. |
---|
451 | |
---|
452 | * On a Sparc, GNU CC aligns all values of type `double' on an 8-byte |
---|
453 | boundary, and it expects every `double' to be so aligned. The Sun |
---|
454 | compiler usually gives `double' values 8-byte alignment, with one |
---|
455 | exception: function arguments of type `double' may not be aligned. |
---|
456 | |
---|
457 | As a result, if a function compiled with Sun CC takes the address |
---|
458 | of an argument of type `double' and passes this pointer of type |
---|
459 | `double *' to a function compiled with GNU CC, dereferencing the |
---|
460 | pointer may cause a fatal signal. |
---|
461 | |
---|
462 | One way to solve this problem is to compile your entire program |
---|
463 | with GNU CC. Another solution is to modify the function that is |
---|
464 | compiled with Sun CC to copy the argument into a local variable; |
---|
465 | local variables are always properly aligned. A third solution is |
---|
466 | to modify the function that uses the pointer to dereference it via |
---|
467 | the following function `access_double' instead of directly with |
---|
468 | `*': |
---|
469 | |
---|
470 | inline double |
---|
471 | access_double (double *unaligned_ptr) |
---|
472 | { |
---|
473 | union d2i { double d; int i[2]; }; |
---|
474 | |
---|
475 | union d2i *p = (union d2i *) unaligned_ptr; |
---|
476 | union d2i u; |
---|
477 | |
---|
478 | u.i[0] = p->i[0]; |
---|
479 | u.i[1] = p->i[1]; |
---|
480 | |
---|
481 | return u.d; |
---|
482 | } |
---|
483 | |
---|
484 | Storing into the pointer can be done likewise with the same union. |
---|
485 | |
---|
486 | * On Solaris, the `malloc' function in the `libmalloc.a' library may |
---|
487 | allocate memory that is only 4 byte aligned. Since GNU CC on the |
---|
488 | Sparc assumes that doubles are 8 byte aligned, this may result in a |
---|
489 | fatal signal if doubles are stored in memory allocated by the |
---|
490 | `libmalloc.a' library. |
---|
491 | |
---|
492 | The solution is to not use the `libmalloc.a' library. Use instead |
---|
493 | `malloc' and related functions from `libc.a'; they do not have |
---|
494 | this problem. |
---|
495 | |
---|
496 | * Sun forgot to include a static version of `libdl.a' with some |
---|
497 | versions of SunOS (mainly 4.1). This results in undefined symbols |
---|
498 | when linking static binaries (that is, if you use `-static'). If |
---|
499 | you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when |
---|
500 | linking, compile and link against the file `mit/util/misc/dlsym.c' |
---|
501 | from the MIT version of X windows. |
---|
502 | |
---|
503 | * The 128-bit long double format that the Sparc port supports |
---|
504 | currently works by using the architecturally defined quad-word |
---|
505 | floating point instructions. Since there is no hardware that |
---|
506 | supports these instructions they must be emulated by the operating |
---|
507 | system. Long doubles do not work in Sun OS versions 4.0.3 and |
---|
508 | earlier, because the kernel emulator uses an obsolete and |
---|
509 | incompatible format. Long doubles do not work in Sun OS version |
---|
510 | 4.1.1 due to a problem in a Sun library. Long doubles do work on |
---|
511 | Sun OS versions 4.1.2 and higher, but GNU CC does not enable them |
---|
512 | by default. Long doubles appear to work in Sun OS 5.x (Solaris |
---|
513 | 2.x). |
---|
514 | |
---|
515 | * On HP-UX version 9.01 on the HP PA, the HP compiler `cc' does not |
---|
516 | compile GNU CC correctly. We do not yet know why. However, GNU CC |
---|
517 | compiled on earlier HP-UX versions works properly on HP-UX 9.01 |
---|
518 | and can compile itself properly on 9.01. |
---|
519 | |
---|
520 | * On the HP PA machine, ADB sometimes fails to work on functions |
---|
521 | compiled with GNU CC. Specifically, it fails to work on functions |
---|
522 | that use `alloca' or variable-size arrays. This is because GNU CC |
---|
523 | doesn't generate HP-UX unwind descriptors for such functions. It |
---|
524 | may even be impossible to generate them. |
---|
525 | |
---|
526 | * Debugging (`-g') is not supported on the HP PA machine, unless you |
---|
527 | use the preliminary GNU tools (*note Installation::.). |
---|
528 | |
---|
529 | * Taking the address of a label may generate errors from the HP-UX |
---|
530 | PA assembler. GAS for the PA does not have this problem. |
---|
531 | |
---|
532 | * Using floating point parameters for indirect calls to static |
---|
533 | functions will not work when using the HP assembler. There simply |
---|
534 | is no way for GCC to specify what registers hold arguments for |
---|
535 | static functions when using the HP assembler. GAS for the PA does |
---|
536 | not have this problem. |
---|
537 | |
---|
538 | * In extremely rare cases involving some very large functions you may |
---|
539 | receive errors from the HP linker complaining about an out of |
---|
540 | bounds unconditional branch offset. This used to occur more often |
---|
541 | in previous versions of GNU CC, but is now exceptionally rare. If |
---|
542 | you should run into it, you can work around by making your |
---|
543 | function smaller. |
---|
544 | |
---|
545 | * GNU CC compiled code sometimes emits warnings from the HP-UX |
---|
546 | assembler of the form: |
---|
547 | |
---|
548 | (warning) Use of GR3 when |
---|
549 | frame >= 8192 may cause conflict. |
---|
550 | |
---|
551 | These warnings are harmless and can be safely ignored. |
---|
552 | |
---|
553 | * The current version of the assembler (`/bin/as') for the RS/6000 |
---|
554 | has certain problems that prevent the `-g' option in GCC from |
---|
555 | working. Note that `Makefile.in' uses `-g' by default when |
---|
556 | compiling `libgcc2.c'. |
---|
557 | |
---|
558 | IBM has produced a fixed version of the assembler. The upgraded |
---|
559 | assembler unfortunately was not included in any of the AIX 3.2 |
---|
560 | update PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1 |
---|
561 | should request PTF U403044 from IBM and users of AIX 3.2 should |
---|
562 | request PTF U416277. See the file `README.RS6000' for more |
---|
563 | details on these updates. |
---|
564 | |
---|
565 | You can test for the presense of a fixed assembler by using the |
---|
566 | command |
---|
567 | |
---|
568 | as -u < /dev/null |
---|
569 | |
---|
570 | If the command exits normally, the assembler fix already is |
---|
571 | installed. If the assembler complains that "-u" is an unknown |
---|
572 | flag, you need to order the fix. |
---|
573 | |
---|
574 | * On the IBM RS/6000, compiling code of the form |
---|
575 | |
---|
576 | extern int foo; |
---|
577 | |
---|
578 | ... foo ... |
---|
579 | |
---|
580 | static int foo; |
---|
581 | |
---|
582 | will cause the linker to report an undefined symbol `foo'. |
---|
583 | Although this behavior differs from most other systems, it is not a |
---|
584 | bug because redefining an `extern' variable as `static' is |
---|
585 | undefined in ANSI C. |
---|
586 | |
---|
587 | * AIX on the RS/6000 provides support (NLS) for environments outside |
---|
588 | of the United States. Compilers and assemblers use NLS to support |
---|
589 | locale-specific representations of various objects including |
---|
590 | floating-point numbers ("." vs "," for separating decimal |
---|
591 | fractions). There have been problems reported where the library |
---|
592 | linked with GCC does not produce the same floating-point formats |
---|
593 | that the assembler accepts. If you have this problem, set the |
---|
594 | LANG environment variable to "C" or "En_US". |
---|
595 | |
---|
596 | * Even if you specify `-fdollars-in-identifiers', you cannot |
---|
597 | successfully use `$' in identifiers on the RS/6000 due to a |
---|
598 | restriction in the IBM assembler. GAS supports these identifiers. |
---|
599 | |
---|
600 | * On the RS/6000, XLC version 1.3.0.0 will miscompile `jump.c'. XLC |
---|
601 | version 1.3.0.1 or later fixes this problem. You can obtain |
---|
602 | XLC-1.3.0.2 by requesting PTF 421749 from IBM. |
---|
603 | |
---|
604 | * There is an assembler bug in versions of DG/UX prior to 5.4.2.01 |
---|
605 | that occurs when the `fldcr' instruction is used. GNU CC uses |
---|
606 | `fldcr' on the 88100 to serialize volatile memory references. Use |
---|
607 | the option `-mno-serialize-volatile' if your version of the |
---|
608 | assembler has this bug. |
---|
609 | |
---|
610 | * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning |
---|
611 | messages from the linker. These warning messages complain of |
---|
612 | mismatched psect attributes. You can ignore them. *Note VMS |
---|
613 | Install::. |
---|
614 | |
---|
615 | * On NewsOS version 3, if you include both of the files `stddef.h' |
---|
616 | and `sys/types.h', you get an error because there are two typedefs |
---|
617 | of `size_t'. You should change `sys/types.h' by adding these |
---|
618 | lines around the definition of `size_t': |
---|
619 | |
---|
620 | #ifndef _SIZE_T |
---|
621 | #define _SIZE_T |
---|
622 | ACTUAL TYPEDEF HERE |
---|
623 | #endif |
---|
624 | |
---|
625 | * On the Alliant, the system's own convention for returning |
---|
626 | structures and unions is unusual, and is not compatible with GNU |
---|
627 | CC no matter what options are used. |
---|
628 | |
---|
629 | * On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different |
---|
630 | convention for structure and union returning. Use the option |
---|
631 | `-mhc-struct-return' to tell GNU CC to use a convention compatible |
---|
632 | with it. |
---|
633 | |
---|
634 | * On Ultrix, the Fortran compiler expects registers 2 through 5 to |
---|
635 | be saved by function calls. However, the C compiler uses |
---|
636 | conventions compatible with BSD Unix: registers 2 through 5 may be |
---|
637 | clobbered by function calls. |
---|
638 | |
---|
639 | GNU CC uses the same convention as the Ultrix C compiler. You can |
---|
640 | use these options to produce code compatible with the Fortran |
---|
641 | compiler: |
---|
642 | |
---|
643 | -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 |
---|
644 | |
---|
645 | * On the WE32k, you may find that programs compiled with GNU CC do |
---|
646 | not work with the standard shared C library. You may need to link |
---|
647 | with the ordinary C compiler. If you do so, you must specify the |
---|
648 | following options: |
---|
649 | |
---|
650 | -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.7.1 -lgcc -lc_s |
---|
651 | |
---|
652 | The first specifies where to find the library `libgcc.a' specified |
---|
653 | with the `-lgcc' option. |
---|
654 | |
---|
655 | GNU CC does linking by invoking `ld', just as `cc' does, and there |
---|
656 | is no reason why it *should* matter which compilation program you |
---|
657 | use to invoke `ld'. If someone tracks this problem down, it can |
---|
658 | probably be fixed easily. |
---|
659 | |
---|
660 | * On the Alpha, you may get assembler errors about invalid syntax as |
---|
661 | a result of floating point constants. This is due to a bug in the |
---|
662 | C library functions `ecvt', `fcvt' and `gcvt'. Given valid |
---|
663 | floating point numbers, they sometimes print `NaN'. |
---|
664 | |
---|
665 | * On Irix 4.0.5F (and perhaps in some other versions), an assembler |
---|
666 | bug sometimes reorders instructions incorrectly when optimization |
---|
667 | is turned on. If you think this may be happening to you, try |
---|
668 | using the GNU assembler; GAS version 2.1 supports ECOFF on Irix. |
---|
669 | |
---|
670 | Or use the `-noasmopt' option when you compile GNU CC with itself, |
---|
671 | and then again when you compile your program. (This is a temporary |
---|
672 | kludge to turn off assembler optimization on Irix.) If this |
---|
673 | proves to be what you need, edit the assembler spec in the file |
---|
674 | `specs' so that it unconditionally passes `-O0' to the assembler, |
---|
675 | and never passes `-O2' or `-O3'. |
---|
676 | |
---|
677 | |
---|
678 | File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble |
---|
679 | |
---|
680 | Problems Compiling Certain Programs |
---|
681 | =================================== |
---|
682 | |
---|
683 | Certain programs have problems compiling. |
---|
684 | |
---|
685 | * Parse errors may occur compiling X11 on a Decstation running |
---|
686 | Ultrix 4.2 because of problems in DEC's versions of the X11 header |
---|
687 | files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding |
---|
688 | `-I/usr/include/mit' to use the MIT versions of the header files, |
---|
689 | using the `-traditional' switch to turn off ANSI C, or fixing the |
---|
690 | header files by adding this: |
---|
691 | |
---|
692 | #ifdef __STDC__ |
---|
693 | #define NeedFunctionPrototypes 0 |
---|
694 | #endif |
---|
695 | |
---|
696 | * If you have trouble compiling Perl on a SunOS 4 system, it may be |
---|
697 | because Perl specifies `-I/usr/ucbinclude'. This accesses the |
---|
698 | unfixed header files. Perl specifies the options |
---|
699 | |
---|
700 | -traditional -Dvolatile=__volatile__ |
---|
701 | -I/usr/include/sun -I/usr/ucbinclude |
---|
702 | -fpcc-struct-return |
---|
703 | |
---|
704 | most of which are unnecessary with GCC 2.4.5 and newer versions. |
---|
705 | You can make a properly working Perl by setting `ccflags' to |
---|
706 | `-fwritable-strings' (implied by the `-traditional' in the |
---|
707 | original options) and `cppflags' to empty in `config.sh', then |
---|
708 | typing `./doSH; make depend; make'. |
---|
709 | |
---|
710 | * On various 386 Unix systems derived from System V, including SCO, |
---|
711 | ISC, and ESIX, you may get error messages about running out of |
---|
712 | virtual memory while compiling certain programs. |
---|
713 | |
---|
714 | You can prevent this problem by linking GNU CC with the GNU malloc |
---|
715 | (which thus replaces the malloc that comes with the system). GNU |
---|
716 | malloc is available as a separate package, and also in the file |
---|
717 | `src/gmalloc.c' in the GNU Emacs 19 distribution. |
---|
718 | |
---|
719 | If you have installed GNU malloc as a separate library package, |
---|
720 | use this option when you relink GNU CC: |
---|
721 | |
---|
722 | MALLOC=/usr/local/lib/libgmalloc.a |
---|
723 | |
---|
724 | Alternatively, if you have compiled `gmalloc.c' from Emacs 19, copy |
---|
725 | the object file to `gmalloc.o' and use this option when you relink |
---|
726 | GNU CC: |
---|
727 | |
---|
728 | MALLOC=gmalloc.o |
---|
729 | |
---|
730 | |
---|
731 | File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble |
---|
732 | |
---|
733 | Incompatibilities of GNU CC |
---|
734 | =========================== |
---|
735 | |
---|
736 | There are several noteworthy incompatibilities between GNU C and most |
---|
737 | existing (non-ANSI) versions of C. The `-traditional' option |
---|
738 | eliminates many of these incompatibilities, *but not all*, by telling |
---|
739 | GNU C to behave like the other C compilers. |
---|
740 | |
---|
741 | * GNU CC normally makes string constants read-only. If several |
---|
742 | identical-looking string constants are used, GNU CC stores only one |
---|
743 | copy of the string. |
---|
744 | |
---|
745 | One consequence is that you cannot call `mktemp' with a string |
---|
746 | constant argument. The function `mktemp' always alters the string |
---|
747 | its argument points to. |
---|
748 | |
---|
749 | Another consequence is that `sscanf' does not work on some systems |
---|
750 | when passed a string constant as its format control string or |
---|
751 | input. This is because `sscanf' incorrectly tries to write into |
---|
752 | the string constant. Likewise `fscanf' and `scanf'. |
---|
753 | |
---|
754 | The best solution to these problems is to change the program to use |
---|
755 | `char'-array variables with initialization strings for these |
---|
756 | purposes instead of string constants. But if this is not possible, |
---|
757 | you can use the `-fwritable-strings' flag, which directs GNU CC to |
---|
758 | handle string constants the same way most C compilers do. |
---|
759 | `-traditional' also has this effect, among others. |
---|
760 | |
---|
761 | * `-2147483648' is positive. |
---|
762 | |
---|
763 | This is because 2147483648 cannot fit in the type `int', so |
---|
764 | (following the ANSI C rules) its data type is `unsigned long int'. |
---|
765 | Negating this value yields 2147483648 again. |
---|
766 | |
---|
767 | * GNU CC does not substitute macro arguments when they appear inside |
---|
768 | of string constants. For example, the following macro in GNU CC |
---|
769 | |
---|
770 | #define foo(a) "a" |
---|
771 | |
---|
772 | will produce output `"a"' regardless of what the argument A is. |
---|
773 | |
---|
774 | The `-traditional' option directs GNU CC to handle such cases |
---|
775 | (among others) in the old-fashioned (non-ANSI) fashion. |
---|
776 | |
---|
777 | * When you use `setjmp' and `longjmp', the only automatic variables |
---|
778 | guaranteed to remain valid are those declared `volatile'. This is |
---|
779 | a consequence of automatic register allocation. Consider this |
---|
780 | function: |
---|
781 | |
---|
782 | jmp_buf j; |
---|
783 | |
---|
784 | foo () |
---|
785 | { |
---|
786 | int a, b; |
---|
787 | |
---|
788 | a = fun1 (); |
---|
789 | if (setjmp (j)) |
---|
790 | return a; |
---|
791 | |
---|
792 | a = fun2 (); |
---|
793 | /* `longjmp (j)' may occur in `fun3'. */ |
---|
794 | return a + fun3 (); |
---|
795 | } |
---|
796 | |
---|
797 | Here `a' may or may not be restored to its first value when the |
---|
798 | `longjmp' occurs. If `a' is allocated in a register, then its |
---|
799 | first value is restored; otherwise, it keeps the last value stored |
---|
800 | in it. |
---|
801 | |
---|
802 | If you use the `-W' option with the `-O' option, you will get a |
---|
803 | warning when GNU CC thinks such a problem might be possible. |
---|
804 | |
---|
805 | The `-traditional' option directs GNU C to put variables in the |
---|
806 | stack by default, rather than in registers, in functions that call |
---|
807 | `setjmp'. This results in the behavior found in traditional C |
---|
808 | compilers. |
---|
809 | |
---|
810 | * Programs that use preprocessing directives in the middle of macro |
---|
811 | arguments do not work with GNU CC. For example, a program like |
---|
812 | this will not work: |
---|
813 | |
---|
814 | foobar ( |
---|
815 | #define luser |
---|
816 | hack) |
---|
817 | |
---|
818 | ANSI C does not permit such a construct. It would make sense to |
---|
819 | support it when `-traditional' is used, but it is too much work to |
---|
820 | implement. |
---|
821 | |
---|
822 | * Declarations of external variables and functions within a block |
---|
823 | apply only to the block containing the declaration. In other |
---|
824 | words, they have the same scope as any other declaration in the |
---|
825 | same place. |
---|
826 | |
---|
827 | In some other C compilers, a `extern' declaration affects all the |
---|
828 | rest of the file even if it happens within a block. |
---|
829 | |
---|
830 | The `-traditional' option directs GNU C to treat all `extern' |
---|
831 | declarations as global, like traditional compilers. |
---|
832 | |
---|
833 | * In traditional C, you can combine `long', etc., with a typedef |
---|
834 | name, as shown here: |
---|
835 | |
---|
836 | typedef int foo; |
---|
837 | typedef long foo bar; |
---|
838 | |
---|
839 | In ANSI C, this is not allowed: `long' and other type modifiers |
---|
840 | require an explicit `int'. Because this criterion is expressed by |
---|
841 | Bison grammar rules rather than C code, the `-traditional' flag |
---|
842 | cannot alter it. |
---|
843 | |
---|
844 | * PCC allows typedef names to be used as function parameters. The |
---|
845 | difficulty described immediately above applies here too. |
---|
846 | |
---|
847 | * PCC allows whitespace in the middle of compound assignment |
---|
848 | operators such as `+='. GNU CC, following the ANSI standard, does |
---|
849 | not allow this. The difficulty described immediately above |
---|
850 | applies here too. |
---|
851 | |
---|
852 | * GNU CC complains about unterminated character constants inside of |
---|
853 | preprocessing conditionals that fail. Some programs have English |
---|
854 | comments enclosed in conditionals that are guaranteed to fail; if |
---|
855 | these comments contain apostrophes, GNU CC will probably report an |
---|
856 | error. For example, this code would produce an error: |
---|
857 | |
---|
858 | #if 0 |
---|
859 | You can't expect this to work. |
---|
860 | #endif |
---|
861 | |
---|
862 | The best solution to such a problem is to put the text into an |
---|
863 | actual C comment delimited by `/*...*/'. However, `-traditional' |
---|
864 | suppresses these error messages. |
---|
865 | |
---|
866 | * Many user programs contain the declaration `long time ();'. In the |
---|
867 | past, the system header files on many systems did not actually |
---|
868 | declare `time', so it did not matter what type your program |
---|
869 | declared it to return. But in systems with ANSI C headers, `time' |
---|
870 | is declared to return `time_t', and if that is not the same as |
---|
871 | `long', then `long time ();' is erroneous. |
---|
872 | |
---|
873 | The solution is to change your program to use `time_t' as the |
---|
874 | return type of `time'. |
---|
875 | |
---|
876 | * When compiling functions that return `float', PCC converts it to a |
---|
877 | double. GNU CC actually returns a `float'. If you are concerned |
---|
878 | with PCC compatibility, you should declare your functions to return |
---|
879 | `double'; you might as well say what you mean. |
---|
880 | |
---|
881 | * When compiling functions that return structures or unions, GNU CC |
---|
882 | output code normally uses a method different from that used on most |
---|
883 | versions of Unix. As a result, code compiled with GNU CC cannot |
---|
884 | call a structure-returning function compiled with PCC, and vice |
---|
885 | versa. |
---|
886 | |
---|
887 | The method used by GNU CC is as follows: a structure or union |
---|
888 | which is 1, 2, 4 or 8 bytes long is returned like a scalar. A |
---|
889 | structure or union with any other size is stored into an address |
---|
890 | supplied by the caller (usually in a special, fixed register, but |
---|
891 | on some machines it is passed on the stack). The |
---|
892 | machine-description macros `STRUCT_VALUE' and |
---|
893 | `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address. |
---|
894 | |
---|
895 | By contrast, PCC on most target machines returns structures and |
---|
896 | unions of any size by copying the data into an area of static |
---|
897 | storage, and then returning the address of that storage as if it |
---|
898 | were a pointer value. The caller must copy the data from that |
---|
899 | memory area to the place where the value is wanted. GNU CC does |
---|
900 | not use this method because it is slower and nonreentrant. |
---|
901 | |
---|
902 | On some newer machines, PCC uses a reentrant convention for all |
---|
903 | structure and union returning. GNU CC on most of these machines |
---|
904 | uses a compatible convention when returning structures and unions |
---|
905 | in memory, but still returns small structures and unions in |
---|
906 | registers. |
---|
907 | |
---|
908 | You can tell GNU CC to use a compatible convention for all |
---|
909 | structure and union returning with the option |
---|
910 | `-fpcc-struct-return'. |
---|
911 | |
---|
912 | * GNU C complains about program fragments such as `0x74ae-0x4000' |
---|
913 | which appear to be two hexadecimal constants separated by the minus |
---|
914 | operator. Actually, this string is a single "preprocessing token". |
---|
915 | Each such token must correspond to one token in C. Since this |
---|
916 | does not, GNU C prints an error message. Although it may appear |
---|
917 | obvious that what is meant is an operator and two values, the ANSI |
---|
918 | C standard specifically requires that this be treated as erroneous. |
---|
919 | |
---|
920 | A "preprocessing token" is a "preprocessing number" if it begins |
---|
921 | with a digit and is followed by letters, underscores, digits, |
---|
922 | periods and `e+', `e-', `E+', or `E-' character sequences. |
---|
923 | |
---|
924 | To make the above program fragment valid, place whitespace in |
---|
925 | front of the minus sign. This whitespace will end the |
---|
926 | preprocessing number. |
---|
927 | |
---|
928 | |
---|
929 | File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble |
---|
930 | |
---|
931 | Fixed Header Files |
---|
932 | ================== |
---|
933 | |
---|
934 | GNU CC needs to install corrected versions of some system header |
---|
935 | files. This is because most target systems have some header files that |
---|
936 | won't work with GNU CC unless they are changed. Some have bugs, some |
---|
937 | are incompatible with ANSI C, and some depend on special features of |
---|
938 | other compilers. |
---|
939 | |
---|
940 | Installing GNU CC automatically creates and installs the fixed header |
---|
941 | files, by running a program called `fixincludes' (or for certain |
---|
942 | targets an alternative such as `fixinc.svr4'). Normally, you don't |
---|
943 | need to pay attention to this. But there are cases where it doesn't do |
---|
944 | the right thing automatically. |
---|
945 | |
---|
946 | * If you update the system's header files, such as by installing a |
---|
947 | new system version, the fixed header files of GNU CC are not |
---|
948 | automatically updated. The easiest way to update them is to |
---|
949 | reinstall GNU CC. (If you want to be clever, look in the makefile |
---|
950 | and you can find a shortcut.) |
---|
951 | |
---|
952 | * On some systems, in particular SunOS 4, header file directories |
---|
953 | contain machine-specific symbolic links in certain places. This |
---|
954 | makes it possible to share most of the header files among hosts |
---|
955 | running the same version of SunOS 4 on different machine models. |
---|
956 | |
---|
957 | The programs that fix the header files do not understand this |
---|
958 | special way of using symbolic links; therefore, the directory of |
---|
959 | fixed header files is good only for the machine model used to |
---|
960 | build it. |
---|
961 | |
---|
962 | In SunOS 4, only programs that look inside the kernel will notice |
---|
963 | the difference between machine models. Therefore, for most |
---|
964 | purposes, you need not be concerned about this. |
---|
965 | |
---|
966 | It is possible to make separate sets of fixed header files for the |
---|
967 | different machine models, and arrange a structure of symbolic |
---|
968 | links so as to use the proper set, but you'll have to do this by |
---|
969 | hand. |
---|
970 | |
---|
971 | * On Lynxos, GNU CC by default does not fix the header files. This |
---|
972 | is because bugs in the shell cause the `fixincludes' script to |
---|
973 | fail. |
---|
974 | |
---|
975 | This means you will encounter problems due to bugs in the system |
---|
976 | header files. It may be no comfort that they aren't GNU CC's |
---|
977 | fault, but it does mean that there's nothing for us to do about |
---|
978 | them. |
---|
979 | |
---|
980 | |
---|
981 | File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble |
---|
982 | |
---|
983 | Standard Libraries |
---|
984 | ================== |
---|
985 | |
---|
986 | GNU CC by itself attempts to be what the ISO/ANSI C standard calls a |
---|
987 | "conforming freestanding implementation". This means all ANSI C |
---|
988 | language features are available, as well as the contents of `float.h', |
---|
989 | `limits.h', `stdarg.h', and `stddef.h'. The rest of the C library is |
---|
990 | supplied by the vendor of the operating system. If that C library |
---|
991 | doesn't conform to the C standards, then your programs might get |
---|
992 | warnings (especially when using `-Wall') that you don't expect. |
---|
993 | |
---|
994 | For example, the `sprintf' function on SunOS 4.1.3 returns `char *' |
---|
995 | while the C standard says that `sprintf' returns an `int'. The |
---|
996 | `fixincludes' program could make the prototype for this function match |
---|
997 | the Standard, but that would be wrong, since the function will still |
---|
998 | return `char *'. |
---|
999 | |
---|
1000 | If you need a Standard compliant library, then you need to find one, |
---|
1001 | as GNU CC does not provide one. The GNU C library (called `glibc') has |
---|
1002 | been ported to a number of operating systems, and provides ANSI/ISO, |
---|
1003 | POSIX, BSD and SystemV compatibility. You could also ask your operating |
---|
1004 | system vendor if newer libraries are available. |
---|
1005 | |
---|
1006 | |
---|
1007 | File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble |
---|
1008 | |
---|
1009 | Disappointments and Misunderstandings |
---|
1010 | ===================================== |
---|
1011 | |
---|
1012 | These problems are perhaps regrettable, but we don't know any |
---|
1013 | practical way around them. |
---|
1014 | |
---|
1015 | * Certain local variables aren't recognized by debuggers when you |
---|
1016 | compile with optimization. |
---|
1017 | |
---|
1018 | This occurs because sometimes GNU CC optimizes the variable out of |
---|
1019 | existence. There is no way to tell the debugger how to compute the |
---|
1020 | value such a variable "would have had", and it is not clear that |
---|
1021 | would be desirable anyway. So GNU CC simply does not mention the |
---|
1022 | eliminated variable when it writes debugging information. |
---|
1023 | |
---|
1024 | You have to expect a certain amount of disagreement between the |
---|
1025 | executable and your source code, when you use optimization. |
---|
1026 | |
---|
1027 | * Users often think it is a bug when GNU CC reports an error for code |
---|
1028 | like this: |
---|
1029 | |
---|
1030 | int foo (struct mumble *); |
---|
1031 | |
---|
1032 | struct mumble { ... }; |
---|
1033 | |
---|
1034 | int foo (struct mumble *x) |
---|
1035 | { ... } |
---|
1036 | |
---|
1037 | This code really is erroneous, because the scope of `struct |
---|
1038 | mumble' in the prototype is limited to the argument list |
---|
1039 | containing it. It does not refer to the `struct mumble' defined |
---|
1040 | with file scope immediately below--they are two unrelated types |
---|
1041 | with similar names in different scopes. |
---|
1042 | |
---|
1043 | But in the definition of `foo', the file-scope type is used |
---|
1044 | because that is available to be inherited. Thus, the definition |
---|
1045 | and the prototype do not match, and you get an error. |
---|
1046 | |
---|
1047 | This behavior may seem silly, but it's what the ANSI standard |
---|
1048 | specifies. It is easy enough for you to make your code work by |
---|
1049 | moving the definition of `struct mumble' above the prototype. |
---|
1050 | It's not worth being incompatible with ANSI C just to avoid an |
---|
1051 | error for the example shown above. |
---|
1052 | |
---|
1053 | * Accesses to bitfields even in volatile objects works by accessing |
---|
1054 | larger objects, such as a byte or a word. You cannot rely on what |
---|
1055 | size of object is accessed in order to read or write the bitfield; |
---|
1056 | it may even vary for a given bitfield according to the precise |
---|
1057 | usage. |
---|
1058 | |
---|
1059 | If you care about controlling the amount of memory that is |
---|
1060 | accessed, use volatile but do not use bitfields. |
---|
1061 | |
---|
1062 | * GNU CC comes with shell scripts to fix certain known problems in |
---|
1063 | system header files. They install corrected copies of various |
---|
1064 | header files in a special directory where only GNU CC will |
---|
1065 | normally look for them. The scripts adapt to various systems by |
---|
1066 | searching all the system header files for the problem cases that |
---|
1067 | we know about. |
---|
1068 | |
---|
1069 | If new system header files are installed, nothing automatically |
---|
1070 | arranges to update the corrected header files. You will have to |
---|
1071 | reinstall GNU CC to fix the new header files. More specifically, |
---|
1072 | go to the build directory and delete the files `stmp-fixinc' and |
---|
1073 | `stmp-headers', and the subdirectory `include'; then do `make |
---|
1074 | install' again. |
---|
1075 | |
---|
1076 | * On 68000 systems, you can get paradoxical results if you test the |
---|
1077 | precise values of floating point numbers. For example, you can |
---|
1078 | find that a floating point value which is not a NaN is not equal |
---|
1079 | to itself. This results from the fact that the the floating point |
---|
1080 | registers hold a few more bits of precision than fit in a `double' |
---|
1081 | in memory. Compiled code moves values between memory and floating |
---|
1082 | point registers at its convenience, and moving them into memory |
---|
1083 | truncates them. |
---|
1084 | |
---|
1085 | You can partially avoid this problem by using the `-ffloat-store' |
---|
1086 | option (*note Optimize Options::.). |
---|
1087 | |
---|
1088 | * On the MIPS, variable argument functions using `varargs.h' cannot |
---|
1089 | have a floating point value for the first argument. The reason |
---|
1090 | for this is that in the absence of a prototype in scope, if the |
---|
1091 | first argument is a floating point, it is passed in a floating |
---|
1092 | point register, rather than an integer register. |
---|
1093 | |
---|
1094 | If the code is rewritten to use the ANSI standard `stdarg.h' |
---|
1095 | method of variable arguments, and the prototype is in scope at the |
---|
1096 | time of the call, everything will work fine. |
---|
1097 | |
---|
1098 | |
---|
1099 | File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble |
---|
1100 | |
---|
1101 | Common Misunderstandings with GNU C++ |
---|
1102 | ===================================== |
---|
1103 | |
---|
1104 | C++ is a complex language and an evolving one, and its standard |
---|
1105 | definition (the ANSI C++ draft standard) is also evolving. As a result, |
---|
1106 | your C++ compiler may occasionally surprise you, even when its behavior |
---|
1107 | is correct. This section discusses some areas that frequently give |
---|
1108 | rise to questions of this sort. |
---|
1109 | |
---|
1110 | * Menu: |
---|
1111 | |
---|
1112 | * Static Definitions:: Static member declarations are not definitions |
---|
1113 | * Temporaries:: Temporaries may vanish before you expect |
---|
1114 | |
---|
1115 | |
---|
1116 | File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings |
---|
1117 | |
---|
1118 | Declare *and* Define Static Members |
---|
1119 | ----------------------------------- |
---|
1120 | |
---|
1121 | When a class has static data members, it is not enough to *declare* |
---|
1122 | the static member; you must also *define* it. For example: |
---|
1123 | |
---|
1124 | class Foo |
---|
1125 | { |
---|
1126 | ... |
---|
1127 | void method(); |
---|
1128 | static int bar; |
---|
1129 | }; |
---|
1130 | |
---|
1131 | This declaration only establishes that the class `Foo' has an `int' |
---|
1132 | named `Foo::bar', and a member function named `Foo::method'. But you |
---|
1133 | still need to define *both* `method' and `bar' elsewhere. According to |
---|
1134 | the draft ANSI standard, you must supply an initializer in one (and |
---|
1135 | only one) source file, such as: |
---|
1136 | |
---|
1137 | int Foo::bar = 0; |
---|
1138 | |
---|
1139 | Other C++ compilers may not correctly implement the standard |
---|
1140 | behavior. As a result, when you switch to `g++' from one of these |
---|
1141 | compilers, you may discover that a program that appeared to work |
---|
1142 | correctly in fact does not conform to the standard: `g++' reports as |
---|
1143 | undefined symbols any static data members that lack definitions. |
---|
1144 | |
---|