![[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.10! root 1: This is Info file gcc.info, produced by Makeinfo version 1.67 from the ! 2: input file gcc.texi. 1.1 root 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.