![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-11 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-11 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.7 root 1: This is Info file gcc.info, produced by Makeinfo-1.55 from the input
1.1 root 2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.8 root 6: Published by the Free Software Foundation 59 Temple Place - Suite 330
7: Boston, MA 02111-1307 USA
1.1.1.5 root 8:
1.1.1.8 root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software
10: Foundation, Inc.
1.1 root 11:
1.1.1.3 root 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.
1.1 root 15:
16: Permission is granted to copy and distribute modified versions of
17: this manual under the conditions for verbatim copying, provided also
1.1.1.7 root 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.
1.1 root 23:
24: Permission is granted to copy and distribute translations of this
25: manual into another language, under the above conditions for modified
1.1.1.3 root 26: versions, except that the sections entitled "GNU General Public
1.1.1.7 root 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.
1.1.1.3 root 31:
32:
1.1.1.8 root 33: File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble
1.1.1.6 root 34:
1.1.1.8 root 35: Installation Problems
36: =====================
1.1.1.6 root 37:
1.1.1.8 root 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.
1.1.1.6 root 41:
1.1.1.8 root 42: * On certain systems, defining certain environment variables such as
43: `CC' can interfere with the functioning of `make'.
1.1.1.6 root 44:
1.1.1.8 root 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::.
1.1.1.6 root 50:
1.1.1.8 root 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.
1.1.1.6 root 57:
1.1.1.8 root 58: The solution is not to use such a directory for building GNU CC.
1.1.1.7 root 59:
1.1.1.8 root 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:
1.1.1.9 ! root 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'.
1.1.1.8 root 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
1.1.1.6 root 258:
1.1.1.8 root 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':
1.1.1.7 root 263:
1.1.1.8 root 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
1.1.1.7 root 268:
1.1.1.8 root 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:
1.1.1.7 root 274:
1.1.1.8 root 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
1.1.1.6 root 349:
350:
1.1.1.8 root 351: File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble
1.1.1.6 root 352:
1.1.1.8 root 353: Cross-Compiler Problems
354: =======================
1.1.1.6 root 355:
1.1.1.8 root 356: You may run into problems with cross compilation on certain machines,
357: for several reasons.
1.1.1.6 root 358:
1.1.1.8 root 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: ==============
1.1.1.7 root 388:
1.1.1.8 root 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'.
1.1.1.6 root 676:
677:
1.1.1.8 root 678: File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble
1.1.1.6 root 679:
1.1.1.8 root 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'.
1.1.1.6 root 709:
1.1.1.8 root 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
1.1.1.6 root 729:
730:
1.1.1.8 root 731: File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble
1.1.1.6 root 732:
1.1.1.8 root 733: Incompatibilities of GNU CC
1.1.1.7 root 734: ===========================
1.1.1.6 root 735:
1.1.1.8 root 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.
1.1.1.6 root 927:
928:
1.1.1.8 root 929: File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble
1.1.1.3 root 930:
1.1.1.8 root 931: Fixed Header Files
932: ==================
1.1.1.3 root 933:
1.1.1.8 root 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.
1.1.1.7 root 979:
1.1.1.8 root 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
1.1.1.7 root 1008:
1.1.1.8 root 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.
1.1.1.5 root 1097:
1098:
1.1.1.8 root 1099: File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble
1100:
1101: Common Misunderstandings with GNU C++
1102: =====================================
1.1.1.5 root 1103:
1.1.1.8 root 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.
1.1.1.5 root 1109:
1.1.1.8 root 1110: * Menu:
1111:
1112: * Static Definitions:: Static member declarations are not definitions
1113: * Temporaries:: Temporaries may vanish before you expect
1.1.1.7 root 1114:
1115:
1.1.1.8 root 1116: File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings
1.1.1.5 root 1117:
1.1.1.8 root 1118: Declare *and* Define Static Members
1119: -----------------------------------
1.1.1.5 root 1120:
1.1.1.8 root 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:
1.1.1.7 root 1123:
1.1.1.8 root 1124: class Foo
1.1.1.7 root 1125: {
1126: ...
1.1.1.8 root 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.
1.1.1.5 root 1144:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.