|
|
1.1 ! root 1: .\" Copyright (c) 1991 Free Software Foundation -*-Text-*- ! 2: .\" See section COPYING for conditions for redistribution ! 3: .\" FIXME: no info here on predefines. Should there be? extra for C++... ! 4: .TH G++ 1 "27dec1991" "GNU Tools" "GNU Tools" ! 5: .de BP ! 6: .sp ! 7: .ti \-.2i ! 8: \(** ! 9: .. ! 10: .SH NAME ! 11: g++ \- GNU project C++ Compiler (v2 preliminary) ! 12: .SH SYNOPSIS ! 13: .RB g++ " [" \c ! 14: .IR option " | " filename " ].\|.\|. ! 15: .SH DESCRIPTION ! 16: The C and C++ compilers are integrated. Both process input files ! 17: through one or more of four stages: preprocessing, compilation, ! 18: assembly, and linking. This man page contains full descriptions for ! 19: .I only ! 20: C++ specific aspects of the compiler, though it also contains ! 21: summaries of some general-purpose options. For a fuller explanation ! 22: of the compiler, see ! 23: .BR gcc ( 1 ). ! 24: ! 25: C++ source files use one of the suffixes `\|\c ! 26: .B .C\c ! 27: \&\|', `\|\c ! 28: .B .cc\c ! 29: \&\|', or `\|\c ! 30: .B .cxx\c ! 31: \&\|'. ! 32: .SH OPTIONS ! 33: There are many command-line options, including options to control ! 34: details of optimization, warnings, and code generation, which are ! 35: common to both ! 36: .B gcc ! 37: and ! 38: .B g++\c ! 39: \&. For full information on all options, see ! 40: .BR gcc ( 1 ). ! 41: ! 42: Options must be separate: `\|\c ! 43: .B \-dr\c ! 44: \&\|' is quite different from `\|\c ! 45: .B \-d \-r ! 46: \&\|'. ! 47: ! 48: Most `\|\c ! 49: .B \-f\c ! 50: \&\|' and `\|\c ! 51: .B \-W\c ! 52: \&\|' options have two contrary forms: ! 53: .BI \-f name ! 54: and ! 55: .BI \-fno\- name\c ! 56: \& (or ! 57: .BI \-W name ! 58: and ! 59: .BI \-Wno\- name\c ! 60: \&). Only the non-default forms are shown here. ! 61: ! 62: .TP ! 63: .B \-c ! 64: Compile or assemble the source files, but do not link. The compiler ! 65: output is an object file corresponding to each source file. ! 66: .TP ! 67: .BI \-D macro ! 68: Define macro \c ! 69: .I macro\c ! 70: \& with the string `\|\c ! 71: .B 1\c ! 72: \&\|' as its definition. ! 73: .TP ! 74: .BI \-D macro = defn ! 75: Define macro \c ! 76: .I macro\c ! 77: \& as \c ! 78: .I defn\c ! 79: \&. ! 80: .TP ! 81: .B \-dynamic ! 82: On systems that support dynamic linking, you can use this option to ! 83: request it explicitly. ! 84: .TP ! 85: .B \-E ! 86: Stop after the preprocessing stage; do not run the compiler proper. The ! 87: output is preprocessed source code, which is sent to the ! 88: standard output. ! 89: .TP ! 90: .BI +e N ! 91: control whether virtual function definitions in classes ! 92: are used to generate code, or only to define interfaces for their ! 93: callers. These options are provided for compatibility with cfront ! 94: 1.x usage; the recommended GNU C++ usage is to use ! 95: .B #pragma interface ! 96: and ! 97: .B ! 98: #pragma implementation\c ! 99: \&, instead. ! 100: ! 101: With `\|\c ! 102: .B +e0\c ! 103: \&\|', virtual function definitions in classes are declared extern; ! 104: the declaration is used only as an interface specification, not to ! 105: generate code for the virtual functions (in this compilation). ! 106: ! 107: With `\|\c ! 108: .B +e1\c ! 109: \&\|', ! 110: .B g++ ! 111: actually generates the code implementing virtual functions ! 112: defined in the code, and makes them publicly visible. ! 113: .TP ! 114: .B \-fall\-virtual ! 115: When you use the `\|\c ! 116: .B \-fall\-virtual\c ! 117: \&\|', all member functions ! 118: (except for constructor functions and new/delete member operators) ! 119: declared in the same class with a ``method-call'' operator method are ! 120: treated as virtual functions of the given class. In effect, all ! 121: of these methods become ``implicitly virtual.'' ! 122: ! 123: This does \c ! 124: .I not\c ! 125: \& mean that all calls to these methods will be made through the ! 126: internal table of virtual functions. There are some circumstances ! 127: under which it is obvious that a call to a given virtual function can ! 128: be made directly, and in these cases the calls still go direct. ! 129: ! 130: The effect of making all methods of a class with a declared ! 131: \&`\|\c ! 132: .B ! 133: operator->()()\c ! 134: \&\|' implicitly virtual using `\|\c ! 135: .B \-fall\-virtual\c ! 136: \&\|' extends ! 137: also to all non-constructor methods of any class derived from such a ! 138: class. ! 139: .TP ! 140: .B \-fdollars\-in\-identifiers ! 141: Permit the use of `\|\c ! 142: .B $\c ! 143: \&\|' in identifiers. ! 144: Traditional C allowed the character `\|\c ! 145: .B $\c ! 146: \&\|' to form part of identifiers; by default, GNU C also ! 147: allows this. However, ANSI C forbids `\|\c ! 148: .B $\c ! 149: \&\|' in identifiers, and GNU C++ also forbids it by default on most ! 150: platforms (though on some platforms it's enabled by default for GNU ! 151: C++ as well). ! 152: .TP ! 153: .B \-felide\-constructors ! 154: Use this option to instruct the compiler to be smarter about when it can ! 155: elide constructors. Without this flag, GNU C++ and cfront both ! 156: generate effectively the same code for: ! 157: .sp ! 158: .br ! 159: A\ foo\ (); ! 160: .br ! 161: A\ x\ (foo\ ());\ \ \ //\ x\ initialized\ by\ `foo\ ()',\ no\ ctor\ called ! 162: .br ! 163: A\ y\ =\ foo\ ();\ \ \ //\ call\ to\ `foo\ ()'\ heads\ to\ temporary, ! 164: .br ! 165: \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ //\ y\ is\ initialized\ from\ the\ temporary. ! 166: .br ! 167: .sp ! 168: Note the difference! With this flag, GNU C++ initializes `\|\c ! 169: .B y\c ! 170: \&\|' directly ! 171: from the call to ! 172: .B foo () ! 173: without going through a temporary. ! 174: .TP ! 175: .B \-fenum\-int\-equiv ! 176: Normally GNU C++ allows conversion of ! 177: .B enum ! 178: to ! 179: .B int\c ! 180: \&, but not the other way around. Use this option if you want GNU C++ ! 181: to allow conversion of ! 182: .B int ! 183: to ! 184: .B enum ! 185: as well. ! 186: .TP ! 187: .B \-fgnu\-binutils ! 188: .TP ! 189: .B \-fno\-gnu\-binutils ! 190: `\|\c ! 191: .B \-fgnu\-binutils ! 192: \&\|' (the default for most, but not all, platforms) makes GNU C++ ! 193: emit extra information for static initialization and finalization. ! 194: This information has to be passed from the assembler to the GNU ! 195: linker. Some assemblers won't pass this information; you must either ! 196: use GNU ! 197: .B as ! 198: or specify the option `\|\c ! 199: .B \-fno\-gnu\-binutils\c ! 200: \&\|'. ! 201: ! 202: With `\|\c ! 203: .B \-fno\-gnu\-binutils\c ! 204: \&\|', you must use the program ! 205: .B collect ! 206: (part of the GCC distribution) for linking. ! 207: .TP ! 208: .B \-fmemoize\-lookups ! 209: .TP ! 210: .B \-fsave\-memoized ! 211: These flags are used to get the compiler to compile programs faster ! 212: using heuristics. They are not on by default since they are only effective ! 213: about half the time. The other half of the time programs compile more ! 214: slowly (and take more memory). ! 215: ! 216: The first time the compiler must build a call to a member function (or ! 217: reference to a data member), it must (1) determine whether the class ! 218: implements member functions of that name; (2) resolve which member ! 219: function to call (which involves figuring out what sorts of type ! 220: conversions need to be made); and (3) check the visibility of the member ! 221: function to the caller. All of this adds up to slower compilation. ! 222: Normally, the second time a call is made to that member function (or ! 223: reference to that data member), it must go through the same lengthy ! 224: process again. This means that code like this ! 225: .sp ! 226: .br ! 227: \ \ cout\ <<\ "This\ "\ <<\ p\ <<\ "\ has\ "\ <<\ n\ <<\ "\ legs.\en"; ! 228: .br ! 229: .sp ! 230: makes six passes through all three steps. By using a software cache, ! 231: a ``hit'' significantly reduces this cost. Unfortunately, using the ! 232: cache introduces another layer of mechanisms which must be implemented, ! 233: and so incurs its own overhead. `\|\c ! 234: .B \-fmemoize\-lookups\c ! 235: \&\|' enables ! 236: the software cache. ! 237: ! 238: Because access privileges (visibility) to members and member functions ! 239: may differ from one function context to the next, ! 240: .B g++ ! 241: may need to flush the cache. With the `\|\c ! 242: .B \-fmemoize\-lookups\c ! 243: \&\|' flag, the cache is flushed after every ! 244: function that is compiled. The `\|\c ! 245: \-fsave\-memoized\c ! 246: \&\|' flag enables the same software cache, but when the compiler ! 247: determines that the context of the last function compiled would yield ! 248: the same access privileges of the next function to compile, it ! 249: preserves the cache. ! 250: This is most helpful when defining many member functions for the same ! 251: class: with the exception of member functions which are friends of ! 252: other classes, each member function has exactly the same access ! 253: privileges as every other, and the cache need not be flushed. ! 254: .TP ! 255: .B \-fno\-default\-inline ! 256: If `\|\c ! 257: .B \-fdefault\-inline\c ! 258: \&\|' is enabled then member functions defined inside class ! 259: scope are compiled inline by default; i.e., you don't need to ! 260: add `\|\c ! 261: .B inline\c ! 262: \&\|' in front of the member function name. By popular ! 263: demand, this option is now the default. To keep GNU C++ from inlining ! 264: these member functions, specify `\|\c ! 265: .B \-fno\-default\-inline\c ! 266: \&\|'. ! 267: .TP ! 268: .B \-fno\-strict\-prototype ! 269: Consider the declaration \c ! 270: .B int foo ();\c ! 271: \&. In C++, this means that the ! 272: function \c ! 273: .B foo\c ! 274: \& takes no arguments. In ANSI C, this is declared ! 275: .B int foo(void);\c ! 276: \&. With the flag `\|\c ! 277: .B \-fno\-strict\-prototype\c ! 278: \&\|', ! 279: declaring functions with no arguments is equivalent to declaring its ! 280: argument list to be untyped, i.e., \c ! 281: .B int foo ();\c ! 282: \& is equivalent to ! 283: saying \c ! 284: .B int foo (...);\c ! 285: \&. ! 286: .TP ! 287: .B \-fnonnull\-objects ! 288: Normally, GNU C++ makes conservative assumptions about objects reached ! 289: through references. For example, the compiler must check that `\|\c ! 290: .B a\c ! 291: \&\|' is not null in code like the following: ! 292: .br ! 293: \ \ \ \ obj\ &a\ =\ g\ (); ! 294: .br ! 295: \ \ \ \ a.f\ (2); ! 296: .br ! 297: Checking that references of this sort have non-null values requires ! 298: extra code, however, and it is unnecessary for many programs. You can ! 299: use `\|\c ! 300: .B \-fnonnull\-objects\c ! 301: \&\|' to omit the checks for null, if your program doesn't require the ! 302: default checking. ! 303: .TP ! 304: .B \-fthis\-is\-variable ! 305: The incorporation of user-defined free store management into C++ has ! 306: made assignment to \c ! 307: .B this\c ! 308: \& an anachronism. Therefore, by default GNU ! 309: C++ treats the type of \c ! 310: .B this\c ! 311: \& in a member function of \c ! 312: .B class X\c ! 313: \& ! 314: to be \c ! 315: .B X *const\c ! 316: \&. In other words, it is illegal to assign to ! 317: \c ! 318: .B this\c ! 319: \& within a class member function. However, for backwards ! 320: compatibility, you can invoke the old behavior by using ! 321: \&`\|\c ! 322: .B \-fthis\-is\-variable\c ! 323: \&\|'. ! 324: .TP ! 325: .B \-g ! 326: Produce debugging information in the operating system's native format ! 327: (for DBX or SDB or DWARF). GDB also can work with this debugging ! 328: information. On most systems that use DBX format, `\|\c ! 329: .B \-g\c ! 330: \&\|' enables use ! 331: of extra debugging information that only GDB can use. ! 332: ! 333: Unlike most other C compilers, GNU CC allows you to use `\|\c ! 334: .B \-g\c ! 335: \&\|' with ! 336: `\|\c ! 337: .B \-O\c ! 338: \&\|'. The shortcuts taken by optimized code may occasionally ! 339: produce surprising results: some variables you declared may not exist ! 340: at all; flow of control may briefly move where you did not expect it; ! 341: some statements may not be executed because they compute constant ! 342: results or their values were already at hand; some statements may ! 343: execute in different places because they were moved out of loops. ! 344: ! 345: Nevertheless it proves possible to debug optimized output. This makes ! 346: it reasonable to use the optimizer for programs that might have bugs. ! 347: .TP ! 348: .BI "\-I" "dir"\c ! 349: \& ! 350: Append directory \c ! 351: .I dir\c ! 352: \& to the list of directories searched for include files. ! 353: .TP ! 354: .BI "\-L" "dir"\c ! 355: \& ! 356: Add directory \c ! 357: .I dir\c ! 358: \& to the list of directories to be searched ! 359: for `\|\c ! 360: .B \-l\c ! 361: \&\|'. ! 362: .TP ! 363: .BI \-l library\c ! 364: \& ! 365: Use the library named \c ! 366: .I library\c ! 367: \& when linking. (C++ programs often require `\|\c ! 368: \-lg++\c ! 369: \&\|' for successful linking.) ! 370: .TP ! 371: .B \-O ! 372: Optimize. Optimizing compilation takes somewhat more time, and a lot ! 373: more memory for a large function. ! 374: ! 375: Without `\|\c ! 376: .B \-O\c ! 377: \&\|', the compiler's goal is to reduce the cost of ! 378: compilation and to make debugging produce the expected results. ! 379: Statements are independent: if you stop the program with a breakpoint ! 380: between statements, you can then assign a new value to any variable or ! 381: change the program counter to any other statement in the function and ! 382: get exactly the results you would expect from the source code. ! 383: ! 384: Without `\|\c ! 385: .B \-O\c ! 386: \&\|', only variables declared \c ! 387: .B register\c ! 388: \& are ! 389: allocated in registers. The resulting compiled code is a little worse ! 390: than produced by PCC without `\|\c ! 391: .B \-O\c ! 392: \&\|'. ! 393: ! 394: With `\|\c ! 395: .B \-O\c ! 396: \&\|', the compiler tries to reduce code size and execution ! 397: time. ! 398: .TP ! 399: .BI "\-o " file\c ! 400: \& ! 401: Place output in file \c ! 402: .I file\c ! 403: \&. ! 404: .TP ! 405: .B \-S ! 406: Stop after the stage of compilation proper; do not assemble. The output ! 407: is an assembler code file for each non-assembler input ! 408: file specified. ! 409: .TP ! 410: .B \-static ! 411: On systems that support dynamic linking, this prevents linking with the shared ! 412: libraries. (`\|\c ! 413: .B \-g\c ! 414: \&\|' also has this effect.) On other systems, this option has no effect. ! 415: .TP ! 416: .B \-traditional ! 417: Attempt to support some aspects of traditional C compilers. ! 418: ! 419: Specifically, for both C and C++ programs: ! 420: .TP ! 421: \ \ \ \(bu ! 422: In the preprocessor, comments convert to nothing at all, rather than ! 423: to a space. This allows traditional token concatenation. ! 424: .TP ! 425: \ \ \ \(bu ! 426: In the preprocessor, macro arguments are recognized within string ! 427: constants in a macro definition (and their values are stringified, ! 428: though without additional quote marks, when they appear in such a ! 429: context). The preprocessor always considers a string constant to end ! 430: at a newline. ! 431: .TP ! 432: \ \ \ \(bu ! 433: The preprocessor does not predefine the macro \c ! 434: .B __STDC__\c ! 435: \& when you use ! 436: `\|\c ! 437: .B \-traditional\c ! 438: \&\|', but still predefines\c ! 439: .B __GNUC__\c ! 440: \& (since the GNU extensions indicated by ! 441: .B __GNUC__\c ! 442: \& are not affected by ! 443: `\|\c ! 444: .B \-traditional\c ! 445: \&\|'). If you need to write header files that work ! 446: differently depending on whether `\|\c ! 447: .B \-traditional\c ! 448: \&\|' is in use, by ! 449: testing both of these predefined macros you can distinguish four ! 450: situations: GNU C, traditional GNU C, other ANSI C compilers, and ! 451: other old C compilers. ! 452: .TP ! 453: \ \ \ \(bu ! 454: In the preprocessor, comments convert to nothing at all, rather than ! 455: to a space. This allows traditional token concatenation. ! 456: .TP ! 457: \ \ \ \(bu ! 458: In the preprocessor, macro arguments are recognized within string ! 459: constants in a macro definition (and their values are stringified, ! 460: though without additional quote marks, when they appear in such a ! 461: context). The preprocessor always considers a string constant to end ! 462: at a newline. ! 463: .TP ! 464: \ \ \ \(bu ! 465: The preprocessor does not predefine the macro \c ! 466: .B __STDC__\c ! 467: \& when you use ! 468: `\|\c ! 469: .B \-traditional\c ! 470: \&\|', but still predefines\c ! 471: .B __GNUC__\c ! 472: \& (since the GNU extensions indicated by ! 473: .B __GNUC__\c ! 474: \& are not affected by ! 475: `\|\c ! 476: .B \-traditional\c ! 477: \&\|'). If you need to write header files that work ! 478: differently depending on whether `\|\c ! 479: .B \-traditional\c ! 480: \&\|' is in use, by ! 481: testing both of these predefined macros you can distinguish four ! 482: situations: GNU C, traditional GNU C, other ANSI C compilers, and ! 483: other old C compilers. ! 484: .PP ! 485: .TP ! 486: \ \ \ \(bu ! 487: String ``constants'' are not necessarily constant; they are stored in ! 488: writable space, and identical looking constants are allocated ! 489: separately. (This is the same as the effect of ! 490: `\|\c ! 491: .B \-fwritable\-strings\c ! 492: \&\|'.) ! 493: ! 494: For C++ programs only (not C), `\|\c ! 495: .B \-traditional\c ! 496: \&\|' has one additional effect: assignment to ! 497: .B this ! 498: is permitted. This is the same as the effect of `\|\c ! 499: .B \-fthis\-is\-variable\c ! 500: \&\|'. ! 501: .TP ! 502: .BI \-U macro ! 503: Undefine macro \c ! 504: .I macro\c ! 505: \&. ! 506: .TP ! 507: .B \-Wall ! 508: Issue warnings for conditions which pertain to usage that we recommend ! 509: avoiding and that we believe is easy to avoid, even in conjunction ! 510: with macros. ! 511: .TP ! 512: .B \-Wenum\-clash ! 513: Warn when converting between different enumeration types. ! 514: .TP ! 515: .B \-Woverloaded\-virtual ! 516: In a derived class, the definitions of virtual functions must match ! 517: the type signature of a virtual function declared in the base class. ! 518: Use this option to request warnings when a derived class declares a ! 519: function that may be an erroneous attempt to define a virtual ! 520: function: that is, warn when a function with the same name as a ! 521: virtual function in the base class, but with a type signature that ! 522: doesn't match any virtual functions from the base class. ! 523: .TP ! 524: .B \-w ! 525: Inhibit all warning messages. ! 526: .PP ! 527: ! 528: .SH PRAGMAS ! 529: Two `\|\c ! 530: .B #pragma\c ! 531: \&\|' directives are supported for GNU C++, to permit using the same ! 532: header file for two purposes: as a definition of interfaces to a given ! 533: object class, and as the full definition of the contents of that object class. ! 534: .TP ! 535: .B #pragma interface ! 536: Use this directive in header files that define object classes, to save ! 537: space in most of the object files that use those classes. Normally, ! 538: local copies of certain information (backup copies of inline member ! 539: functions, debugging information, and the internal tables that ! 540: implement virtual functions) must be kept in each object file that ! 541: includes class definitions. You can use this pragma to avoid such ! 542: duplication. When a header file containing `\|\c ! 543: .B #pragma interface\c ! 544: \&\|' is included in a compilation, this auxiliary information ! 545: will not be generated (unless the main input source file itself uses ! 546: `\|\c ! 547: .B #pragma implementation\c ! 548: \&\|'). Instead, the object files will contain references to be ! 549: resolved at link time. ! 550: .tr !" ! 551: .TP ! 552: .B #pragma implementation ! 553: .TP ! 554: .BI "#pragma implementation !" objects .h! ! 555: Use this pragma in a main input file, when you want full output from ! 556: included header files to be generated (and made globally visible). ! 557: The included header file, in turn, should use `\|\c ! 558: .B #pragma interface\c ! 559: \&\|'. ! 560: Backup copies of inline member functions, debugging information, and ! 561: the internal tables used to implement virtual functions are all ! 562: generated in implementation files. ! 563: ! 564: If you use `\|\c ! 565: .B #pragma implementation\c ! 566: \&\|' with no argument, it applies to an include file with the same ! 567: basename as your source file; for example, in `\|\c ! 568: .B allclass.cc\c ! 569: \&\|', `\|\c ! 570: .B #pragma implementation\c ! 571: \&\|' by itself is equivalent to `\|\c ! 572: .B ! 573: #pragma implementation "allclass.h"\c ! 574: \&\|'. Use the string argument if you want a single implementation ! 575: file to include code from multiple header files. ! 576: ! 577: There is no way to split up the contents of a single header file into ! 578: multiple implementation files. ! 579: .SH FILES ! 580: .ta \w'LIBDIR/g++\-include 'u ! 581: file.h C header (preprocessor) file ! 582: .br ! 583: file.i preprocessed C source file ! 584: .br ! 585: file.C C++ source file ! 586: .br ! 587: file.cc C++ source file ! 588: .br ! 589: file.cxx C++ source file ! 590: .br ! 591: file.s assembly language file ! 592: .br ! 593: file.o object file ! 594: .br ! 595: a.out link edited output ! 596: .br ! 597: \fITMPDIR\fR/cc\(** temporary files ! 598: .br ! 599: \fILIBDIR\fR/cpp preprocessor ! 600: .br ! 601: \fILIBDIR\fR/cc1plus compiler ! 602: .br ! 603: \fILIBDIR\fR/collect linker front end needed on some machines ! 604: .br ! 605: \fILIBDIR\fR/libgcc.a GCC subroutine library ! 606: .br ! 607: /lib/crt[01n].o start-up routine ! 608: .br ! 609: \fILIBDIR\fR/ccrt0 additional start-up routine for C++ ! 610: .br ! 611: /lib/libc.a standard C library, see ! 612: .IR intro (3) ! 613: .br ! 614: /usr/include standard directory for ! 615: .B #include ! 616: files ! 617: .br ! 618: \fILIBDIR\fR/include standard gcc directory for ! 619: .B #include ! 620: files ! 621: .br ! 622: \fILIBDIR\fR/g++\-include additional g++ directory for ! 623: .B #include ! 624: .sp ! 625: .I LIBDIR ! 626: is usually ! 627: .B /usr/local/lib/\c ! 628: .IR machine / version . ! 629: .br ! 630: .I TMPDIR ! 631: comes from the environment variable ! 632: .B TMPDIR ! 633: (default ! 634: .B /usr/tmp ! 635: if available, else ! 636: .B /tmp\c ! 637: \&). ! 638: .SH "SEE ALSO" ! 639: gcc(1), cpp(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1). ! 640: .br ! 641: .RB "`\|" gcc "\|', `\|" cpp \|', ! 642: .RB `\| as \|', `\| ld \|', ! 643: and ! 644: .RB `\| gdb \|' ! 645: entries in ! 646: .B info\c ! 647: \&. ! 648: .br ! 649: .I ! 650: Using and Porting GNU CC (for version 2.0)\c ! 651: , Richard M. Stallman, November 1990; ! 652: .I ! 653: The C Preprocessor\c ! 654: , Richard M. Stallman, July 1990; ! 655: .I ! 656: Using GDB: A Guide to the GNU Source-Level Debugger\c ! 657: , Richard M. Stallman and Roland H. Pesch, December 1991; ! 658: .I ! 659: Using as: the GNU Assembler\c ! 660: , Dean Elsner, Jay Fenlason & friends, March 1991; ! 661: .I ! 662: gld: the GNU linker\c ! 663: , Steve Chamberlain and Roland Pesch, April 1991. ! 664: ! 665: .SH BUGS ! 666: Report bugs to ! 667: .BR bug\[email protected] . ! 668: Bugs tend actually to be fixed if they can be isolated, so it is in your ! 669: interest to report them in such a way that they can be easily reproduced. ! 670: .SH COPYING ! 671: Copyright (c) 1991 Free Software Foundation, Inc. ! 672: .PP ! 673: Permission is granted to make and distribute verbatim copies of ! 674: this manual provided the copyright notice and this permission notice ! 675: are preserved on all copies. ! 676: .PP ! 677: Permission is granted to copy and distribute modified versions of this ! 678: manual under the conditions for verbatim copying, provided that the ! 679: entire resulting derived work is distributed under the terms of a ! 680: permission notice identical to this one. ! 681: .PP ! 682: Permission is granted to copy and distribute translations of this ! 683: manual into another language, under the above conditions for modified ! 684: versions, except that this permission notice may be included in ! 685: translations approved by the Free Software Foundation instead of in ! 686: the original English. ! 687: .SH AUTHORS ! 688: See the GNU CC Manual for the contributors to GNU CC.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.