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