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