Update of /cvsroot/mingw/doc/chm/gnu/gcc In directory usw-pr-cvs1:/tmp/cvs-serv2007/gnu/gcc Added Files: Makefile bugreport.texi bugs.texi bugs0.texi c-tree.texi collect2.texi configfiles.texi configterms.texi contrib.texi contribute.texi copying-lib.texi cpp.texi cppenv.texi cppinternals.texi cppopts.texi extend.texi fdl.texi ffe.texi fragments.texi frontends.texi functions.texi funding.texi g77.texi gcc-common.texi gcc.texi gccint.texi gcj.texi gcov.texi gnat-style.texi gnat_rm.texi gnat_ug.texi gnu.texi gpl.texi headerdirs.texi hostconfig.texi install-old.texi install.texi intdoc.texi interface.texi invoke.texi languages.texi libiberty.texi makefile.texi md.texi news.texi news0.texi objc.texi obstacks.texi passes.texi portability.texi root.texi rtl.texi service.texi sourcebuild.texi standards.texi tm.texi trouble.texi vms.texi Log Message: Initial import to cvs of the CHMs sources. --- NEW FILE: Makefile --- TOP_DIR = ../.. VERSION = 3.1 BOOKS = cpp.texi cppinternals.texi g77.texi gcc.texi gccint.texi gcj.texi gnat_ug.texi gnat_rm.texi gnat-style.texi libiberty.texi include $(TOP_DIR)/rules.mak --- NEW FILE: bugreport.texi --- @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, @c 1999, 2000, 2001 Free Software Foundation, Inc. @c This is part of the GCC manual. @c For copying conditions, see the file gcc.texi. @node Bugs @chapter Reporting Bugs @cindex bugs @cindex reporting bugs Your bug reports play an essential role in making GCC reliable. When you encounter a problem, the first thing to do is to see if it is already known. @xref{Trouble}. If it isn't known, then you should report the problem. Reporting a bug may help you by bringing a solution to your problem, or it may not. (If it does not, look in the service directory; see @ref{Service}.) In any case, the principal function of a bug report is to help the entire community by making the next version of GCC work better. Bug reports are your contribution to the maintenance of GCC@. Since the maintainers are very overloaded, we cannot respond to every bug report. However, if the bug has not been fixed, we are likely to send you a patch and ask you to tell us whether it works. In order for a bug report to serve its purpose, you must include the information that makes for fixing the bug. @menu * Criteria: Bug Criteria. Have you really found a bug? * Where: Bug Lists. Where to send your bug report. * Reporting: Bug Reporting. How to report a bug effectively. * GNATS: gccbug. You can use a bug reporting tool. * Known: Trouble. Known problems. * Help: Service. Where to ask for help. @end menu @node Bug Criteria,Bug Lists,,Bugs @section Have You Found a Bug? @cindex bug criteria If you are not sure whether you have found a bug, here are some guidelines: @itemize @bullet @cindex fatal signal @cindex core dump @item If the compiler gets a fatal signal, for any input whatever, that is a compiler bug. Reliable compilers never crash. @cindex invalid assembly code @cindex assembly code, invalid @item If the compiler produces invalid assembly code, for any input whatever (except an @code{asm} statement), that is a compiler bug, unless the compiler reports errors (not just warnings) which would ordinarily prevent the assembler from being run. @cindex undefined behavior @cindex undefined function value @cindex increment operators @item If the compiler produces valid assembly code that does not correctly execute the input source code, that is a compiler bug. However, you must double-check to make sure, because you may have run into an incompatibility between GNU C and traditional C (@pxref{Incompatibilities}). These incompatibilities might be considered bugs, but they are inescapable consequences of valuable features. Or you may have a program whose behavior is undefined, which happened by chance to give the desired results with another C or C++ compiler. For example, in many nonoptimizing compilers, you can write @samp{x;} at the end of a function instead of @samp{return x;}, with the same results. But the value of the function is undefined if @code{return} is omitted; it is not a bug when GCC produces different results. Problems often result from expressions with two increment operators, as in @code{f (*p++, *p++)}. Your previous compiler might have interpreted that expression the way you intended; GCC might interpret it another way. Neither compiler is wrong. The bug is in your code. After you have localized the error to a single source line, it should be easy to check for these things. If your program is correct and well defined, you have found a compiler bug. @item If the compiler produces an error message for valid input, that is a compiler bug. @cindex invalid input @item If the compiler does not produce an error message for invalid input, that is a compiler bug. However, you should note that your idea of ``invalid input'' might be my idea of ``an extension'' or ``support for traditional practice''. @item If you are an experienced user of one of the languages GCC supports, your suggestions for improvement of GCC are welcome in any case. @end itemize @node Bug Lists,Bug Reporting,Bug Criteria,Bugs @section Where to Report Bugs @cindex bug report mailing lists @kindex gcc-bugs@@gcc.gnu.org or bug-gcc@@gnu.org Send bug reports for the GNU Compiler Collection to @email{gcc-bugs@@gcc.gnu.org}. In accordance with the GNU-wide convention, in which bug reports for tool ``foo'' are sent to @samp{bug-foo@@gnu.org}, the address @email{bug-gcc@@gnu.org} may also be used; it will forward to the address given above. Please read @uref{http://gcc.gnu.org/bugs.html} for additional and/or more up-to-date bug reporting instructions before you post a bug report. @node Bug Reporting,gccbug,Bug Lists,Bugs @section How to Report Bugs @cindex compiler bugs, reporting The fundamental principle of reporting bugs usefully is this: @strong{report all the facts}. If you are not sure whether to state a fact or leave it out, state it! Often people omit facts because they think they know what causes the problem and they conclude that some details don't matter. Thus, you might assume that the name of the variable you use in an example does not matter. Well, probably it doesn't, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that name is stored in memory; perhaps, if the name were different, the contents of that location would fool the compiler into doing the right thing despite the bug. Play it safe and give a specific, complete example. That is the easiest thing for you to do, and the most helpful. Keep in mind that the purpose of a bug report is to enable someone to fix the bug if it is not known. It isn't very important what happens if the bug is already known. Therefore, always write your bug reports on the assumption that the bug is not known. Sometimes people give a few sketchy facts and ask, ``Does this ring a bell?'' This cannot help us fix a bug, so it is basically useless. We respond by asking for enough details to enable us to investigate. You might as well expedite matters by sending them to begin with. Try to make your bug report self-contained. If we have to ask you for more information, it is best if you include all the previous information in your response, as well as the information that was missing. Please report each bug in a separate message. This makes it easier for us to track which bugs have been fixed and to forward your bugs reports to the appropriate maintainer. To enable someone to investigate the bug, you should include all these things: @itemize @bullet @item The version of GCC@. You can get this by running it with the @option{-v} option. Without this, we won't know whether there is any point in looking for the bug in the current version of GCC@. @item A complete input file that will reproduce the bug. If the bug is in the C preprocessor, send a source file and any header files that it requires. If the bug is in the compiler proper (@file{cc1}), send the preprocessor output generated by adding @option{-save-temps} to the compilation command (@pxref{Debugging Options}). When you do this, use the same @option{-I}, @option{-D} or @option{-U} options that you used in actual compilation. Then send the @var{input}.i or @var{input}.ii files generated. A single statement is not enough of an example. In order to compile it, it must be embedded in a complete file of compiler input; and the bug might depend on the details of how this is done. Without a real example one can compile, all anyone can do about your bug report is wish you luck. It would be futile to try to guess how to provoke the bug. For example, bugs in register allocation and reloading frequently depend on every little detail of the function they happen in. Even if the input file that fails comes from a GNU program, you should still send the complete test case. Don't ask the GCC maintainers to do the extra work of obtaining the program in question---they are all overworked as it is. Also, the problem may depend on what is in the header files on your system; it is unreliable for the GCC maintainers to try the problem with the header files available to them. By sending CPP output, you can eliminate this source of uncertainty and save us a certain percentage of wild goose chases. @item The command arguments you gave GCC to compile that example and observe the bug. For example, did you use @option{-O}? To guarantee you won't omit something important, list all the options. If we were to try to guess the arguments, we would probably guess wrong and then we would not encounter the bug. @item The type of machine you are using, and the operating system name and version number. @item The operands you gave to the @code{configure} command when you installed the compiler. @item A complete list of any modifications you have made to the compiler source. (We don't promise to investigate the bug unless it happens in an unmodified compiler. But if you've made modifications and don't tell us, then you are sending us on a wild goose chase.) Be precise about these changes. A description in English is not enough---send a context diff for them. Adding files of your own (such as a machine description for a machine we don't support) is a modification of the compiler source. @item Details of any other deviations from the standard procedure for installing GCC@. @item A description of what behavior you observe that you believe is incorrect. For example, ``The compiler gets a fatal signal,'' or, ``The assembler instruction at line 208 in the output is incorrect.'' Of course, if the bug is that the compiler gets a fatal signal, then one can't miss it. But if the bug is incorrect output, the maintainer might not notice unless it is glaringly wrong. None of us has time to study all the assembler code from a 50-line C program just on the chance that one instruction might be wrong. We need @emph{you} to do this part! Even if the problem you experience is a fatal signal, you should still say so explicitly. Suppose something strange is going on, such as, your copy of the compiler is out of synch, or you have encountered a bug in the C library on your system. (This has happened!) Your copy might crash and the copy here would not. If you @i{said} to expect a crash, then when the compiler here fails to crash, we would know that the bug was not happening. If you don't say to expect a crash, then we would not know whether the bug was happening. We would not be able to draw any conclusion from our observations. If the problem is a diagnostic when compiling GCC with some other compiler, say whether it is a warning or an error. Often the observed symptom is incorrect output when your program is run. Sad to say, this is not enough information unless the program is short and simple. None of us has time to study a large program to figure out how it would work if compiled correctly, much less which line of it was compiled wrong. So you will have to do that. Tell us which source line it is, and what incorrect result happens when that line is executed. A person who understands the program can find this as easily as finding a bug in the program itself. @item If you send examples of assembler code output from GCC, please use @option{-g} when you make them. The debugging information includes source line numbers which are essential for correlating the output with the input. @item If you wish to mention something in the GCC source, refer to it by context, not by line number. The line numbers in the development sources don't match those in your sources. Your line numbers would convey no useful information to the maintainers. @item Additional information from a debugger might enable someone to find a problem on a machine which he does not have available. However, you need to think when you collect this information if you want it to have any chance of being useful. @cindex backtrace for bug reports For example, many people send just a backtrace, but that is never useful by itself. A simple backtrace with arguments conveys little about GCC because the compiler is largely data-driven; the same functions are called over and over for different RTL insns, doing different things depending on the details of the insn. Most of the arguments listed in the backtrace are useless because they are pointers to RTL list structure. The numeric values of the pointers, which the debugger prints in the backtrace, have no significance whatever; all that matters is the contents of the objects they point to (and most of the contents are other such pointers). In addition, most compiler passes consist of one or more loops that scan the RTL insn sequence. The most vital piece of information about such a loop---which insn it has reached---is usually in a local variable, not in an argument. @findex debug_rtx What you need to provide in addition to a backtrace are the values of the local variables for several stack frames up. When a local variable or an argument is an RTX, first print its value and then use the GDB command @code{pr} to print the RTL expression that it points to. (If GDB doesn't run on your machine, use your debugger to call the function @code{debug_rtx} with the RTX as an argument.) In general, whenever a variable is a pointer, its value is no use without the data it points to. @end itemize Here are some things that are not necessary: @itemize @bullet @item A description of the envelope of the bug. Often people who encounter a bug spend a lot of time investigating which changes to the input file will make the bug go away and which changes will not affect it. This is often time consuming and not very useful, because the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples. You might as well save your time for something else. Of course, if you can find a simpler example to report @emph{instead} of the original one, that is a convenience. Errors in the output will be easier to spot, running under the debugger will take less time, etc. Most GCC bugs involve just one function, so the most straightforward way to simplify an example is to delete all the function definitions except the one where the bug occurs. Those earlier in the file may be replaced by external declarations if the crucial function depends on them. (Exception: inline functions may affect compilation of functions defined later in the file.) However, simplification is not vital; if you don't want to do this, report the bug anyway and send the entire test case you used. @item In particular, some people insert conditionals @samp{#ifdef BUG} around a statement which, if removed, makes the bug not happen. These are just clutter; we won't pay any attention to them anyway. Besides, you should send us cpp output, and that can't have conditionals. @item A patch for the bug. A patch for the bug is useful if it is a good one. But don't omit the necessary information, such as the test case, on the assumption that a patch is all we need. We might see problems with your patch and decide to fix the problem another way, or we might not understand it at all. Sometimes with a program as complicated as GCC it is very hard to construct an example that will make the program follow a certain path through the code. If you don't send the example, we won't be able to construct one, so we won't be able to verify that the bug is fixed. And if we can't understand what bug you are trying to fix, or why your patch should be an improvement, we won't install it. A test case will help us to understand. See @uref{http://gcc.gnu.org/contribute.html} for guidelines on how to make it easy for us to understand and install your patches. @item A guess about what the bug is or what it depends on. Such guesses are usually wrong. Even I can't guess right about such things without first using the debugger to find the facts. @item A core dump file. We have no way of examining a core dump for your type of machine unless we have an identical system---and if we do have one, we should be able to reproduce the crash ourselves. @end itemize @node gccbug,, Bug Reporting, Bugs @section The gccbug script @cindex gccbug script To simplify creation of bug reports, and to allow better tracking of reports, we use the GNATS bug tracking system. Part of that system is the @code{gccbug} script. This is a Unix shell script, so you need a shell to run it. It is normally installed in the same directory where @code{gcc} is installed. The gccbug script is derived from send-pr, @pxref{using send-pr,,Creating new Problem Reports,send-pr,Reporting Problems}. When invoked, it starts a text editor so you can fill out the various fields of the report. When the you quit the editor, the report is automatically send to the bug reporting address. A number of fields in this bug report form are specific to GCC, and are explained at @uref{http://gcc.gnu.org/gnats.html}. --- NEW FILE: bugs.texi --- @c Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc. @c This is part of the G77 manual. @c For copying conditions, see the file g77.texi. @c The text of this file appears in the file BUGS @c in the G77 distribution, as well as in the G77 manual. @c Keep this the same as the dates above, since it's used @c in the standalone derivations of this file (e.g. BUGS). @set copyrights-bugs 1995,1996,1997,1998,1999,2000,2001,2002 @set last-update-bugs 2002-02-01 @include root.texi @ifset DOC-BUGS @c The immediately following lines apply to the BUGS file @c which is derived from this file. @emph{Note:} This file is automatically generated from the files @file{bugs0.texi} and @file{bugs.texi}. @file{BUGS} is @emph{not} a source file, although it is normally included within source distributions. This file lists known bugs in the @value{which-g77} version of the GNU Fortran compiler. Copyright (C) @value{copyrights-bugs} Free Software Foundation, Inc. You may copy, distribute, and modify it freely as long as you preserve this copyright notice and permission notice. @node Top,,, (dir) @chapter Known Bugs In GNU Fortran @end ifset @ifset DOC-G77 @node Known Bugs @section Known Bugs In GNU Fortran @end ifset This section identifies bugs that @code{g77} @emph{users} might run into in the @value{which-g77} version of @code{g77}. This includes bugs that are actually in the @code{gcc} back end (GBE) or in @code{libf2c}, because those sets of code are at least somewhat under the control of (and necessarily intertwined with) @code{g77}, so it isn't worth separating them out. @ifset DOC-G77 For information on bugs in @emph{other} versions of @code{g77}, see @ref{News,,News About GNU Fortran}. There, lists of bugs fixed in various versions of @code{g77} can help determine what bugs existed in prior versions. @end ifset @ifset DOC-BUGS For information on bugs in @emph{other} versions of @code{g77}, see @file{@value{path-g77}/NEWS}. There, lists of bugs fixed in various versions of @code{g77} can help determine what bugs existed in prior versions. @end ifset @ifset DEVELOPMENT @emph{Warning:} The information below is still under development, and might not accurately reflect the @code{g77} code base of which it is a part. Efforts are made to keep it somewhat up-to-date, but they are particularly concentrated on any version of this information that is distributed as part of a @emph{released} @code{g77}. In particular, while this information is intended to apply to the @value{which-g77} version of @code{g77}, only an official @emph{release} of that version is expected to contain documentation that is most consistent with the @code{g77} product in that version. @end ifset An online, ``live'' version of this document (derived directly from the mainline, development version of @code{g77} within @code{gcc}) is available via @uref{http://www.gnu.org/software/gcc/onlinedocs/g77_bugs.html}. Follow the ``Known Bugs'' link. The following information was last updated on @value{last-update-bugs}: @itemize @bullet @item @code{g77} fails to warn about use of a ``live'' iterative-DO variable as an implied-DO variable in a @code{WRITE} or @code{PRINT} statement (although it does warn about this in a @code{READ} statement). @item Something about @code{g77}'s straightforward handling of label references and definitions sometimes prevents the GBE from unrolling loops. Until this is solved, try inserting or removing @code{CONTINUE} statements as the terminal statement, using the @code{END DO} form instead, and so on. @item Some confusion in diagnostics concerning failing @code{INCLUDE} statements from within @code{INCLUDE}'d or @code{#include}'d files. @cindex integer constants @cindex constants, integer @item @code{g77} assumes that @code{INTEGER(KIND=1)} constants range from @samp{-2**31} to @samp{2**31-1} (the range for two's-complement 32-bit values), instead of determining their range from the actual range of the type for the configuration (and, someday, for the constant). Further, it generally doesn't implement the handling of constants very well in that it makes assumptions about the configuration that it no longer makes regarding variables (types). Included with this item is the fact that @code{g77} doesn't recognize that, on IEEE-754/854-compliant systems, @samp{0./0.} should produce a NaN and no warning instead of the value @samp{0.} and a warning. @cindex compiler speed @cindex speed, of compiler @cindex compiler memory usage @cindex memory usage, of compiler @cindex large aggregate areas @cindex initialization, bug @cindex DATA statement @cindex statements, DATA @item @code{g77} uses way too much memory and CPU time to process large aggregate areas having any initialized elements. For example, @samp{REAL A(1000000)} followed by @samp{DATA A(1)/1/} takes up way too much time and space, including the size of the generated assembler file. Version 0.5.18 improves cases like this---specifically, cases of @emph{sparse} initialization that leave large, contiguous areas uninitialized---significantly. However, even with the improvements, these cases still require too much memory and CPU time. (Version 0.5.18 also improves cases where the initial values are zero to a much greater degree, so if the above example ends with @samp{DATA A(1)/0/}, the compile-time performance will be about as good as it will ever get, aside from unrelated improvements to the compiler.) Note that @code{g77} does display a warning message to notify the user before the compiler appears to hang. @ifset DOC-G77 A warning message is issued when @code{g77} sees code that provides initial values (e.g. via @code{DATA}) to an aggregate area (@code{COMMON} or @code{EQUIVALENCE}, or even a large enough array or @code{CHARACTER} variable) that is large enough to increase @code{g77}'s compile time by roughly a factor of 10. This size currently is quite small, since @code{g77} currently has a known bug requiring too much memory and time to handle such cases. In @file{@value{path-g77}/data.c}, the macro @code{FFEDATA_sizeTOO_BIG_INIT_} is defined to the minimum size for the warning to appear. The size is specified in storage units, which can be bytes, words, or whatever, on a case-by-case basis. After changing this macro definition, you must (of course) rebuild and reinstall @code{g77} for the change to take effect. Note that, as of version 0.5.18, improvements have reduced the scope of the problem for @emph{sparse} initialization of large arrays, especially those with large, contiguous uninitialized areas. However, the warning is issued at a point prior to when @code{g77} knows whether the initialization is sparse, and delaying the warning could mean it is produced too late to be helpful. Therefore, the macro definition should not be adjusted to reflect sparse cases. Instead, adjust it to generate the warning when densely initialized arrays begin to cause responses noticeably slower than linear performance would suggest. @end ifset @cindex code, displaying main source @cindex displaying main source code @cindex debugging main source code @cindex printing main source @item When debugging, after starting up the debugger but before being able to see the source code for the main program unit, the user must currently set a breakpoint at @code{MAIN__} (or @code{MAIN___} or @code{MAIN_} if @code{MAIN__} doesn't exist) and run the program until it hits the breakpoint. At that point, the main program unit is activated and about to execute its first executable statement, but that's the state in which the debugger should start up, as is the case for languages like C. @cindex debugger @item Debugging @code{g77}-compiled code using debuggers other than @code{gdb} is likely not to work. Getting @code{g77} and @code{gdb} to work together is a known problem---getting @code{g77} to work properly with other debuggers, for which source code often is unavailable to @code{g77} developers, seems like a much larger, unknown problem, and is a lower priority than making @code{g77} and @code{gdb} work together properly. On the other hand, information about problems other debuggers have with @code{g77} output might make it easier to properly fix @code{g77}, and perhaps even improve @code{gdb}, so it is definitely welcome. Such information might even lead to all relevant products working together properly sooner. @cindex Alpha, support @cindex support, Alpha @item @code{g77} doesn't work perfectly on 64-bit configurations such as the Digital Semiconductor (``DEC'') Alpha. This problem is largely resolved as of version 0.5.23. @cindex padding @cindex structures @cindex common blocks @cindex equivalence areas @item @code{g77} currently inserts needless padding for things like @samp{COMMON A,IPAD} where @samp{A} is @code{CHARACTER*1} and @samp{IPAD} is @code{INTEGER(KIND=1)} on machines like x86, because the back end insists that @samp{IPAD} be aligned to a 4-byte boundary, but the processor has no such requirement (though it is usually good for performance). The @code{gcc} back end needs to provide a wider array of specifications of alignment requirements and preferences for targets, and front ends like @code{g77} should take advantage of this when it becomes available. @cindex complex performance @cindex aliasing @item The @code{libf2c} routines that perform some run-time arithmetic on @code{COMPLEX} operands were modified circa version 0.5.20 of @code{g77} to work properly even in the presence of aliased operands. While the @code{g77} and @code{netlib} versions of @code{libf2c} differ on how this is accomplished, the main differences are that we believe the @code{g77} version works properly even in the presence of @emph{partially} aliased operands. However, these modifications have reduced performance on targets such as x86, due to the extra copies of operands involved. @end itemize --- NEW FILE: bugs0.texi --- \input texinfo @c -*-texinfo-*- @c %**start of header @setfilename BUGS @c %**end of header @c This tells bugs.texi that it's generating just the BUGS file. @set DOC-BUGS @include bugs.texi @bye --- NEW FILE: c-tree.texi --- @c Copyright (c) 1999, 2000, 2001 Free Software Foundation, Inc. @c Free Software Foundation, Inc. @c This is part of the GCC manual. @c For copying conditions, see the file gcc.texi. @c --------------------------------------------------------------------- @c Trees @c --------------------------------------------------------------------- @node Trees @chapter Trees: The intermediate representation used by the C and C++ front ends @cindex Trees @cindex C/C++ Internal Representation This chapter documents the internal representation used by GCC to represent C and C++ source programs. When presented with a C or C++ source program, GCC parses the program, performs semantic analysis (including the generation of error messages), and then produces the internal representation described here. This representation contains a [...2276 lines suppressed...] If @code{AGGR_INIT_VIA_CTOR_P} holds of the @code{AGGR_INIT_EXPR}, then the initialization is via a constructor call. The address of the third operand of the @code{AGGR_INIT_EXPR}, which is always a @code{VAR_DECL}, is taken, and this value replaces the first argument in the argument list. In this case, the value of the expression is the @code{VAR_DECL} given by the third operand to the @code{AGGR_INIT_EXPR}; constructors do not return a value. @item VTABLE_REF A @code{VTABLE_REF} indicates that the interior expression computes a value that is a vtable entry. It is used with @option{-fvtable-gc} to track the reference through to front end to the middle end, at which point we transform this to a @code{REG_VTABLE_REF} note, which survives the balance of code generation. The first operand is the expression that computes the vtable reference. The second operand is the @code{VAR_DECL} of the vtable. The third operand is an @code{INTEGER_CST} of the byte offset into the vtable. @end table --- NEW FILE: collect2.texi --- @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc. @c This is part of the GCC manual. @c For copying conditions, see the file gcc.texi. @node Collect2 @chapter @code{collect2} GNU CC uses a utility called @code{collect2} on nearly all systems to arrange to call various initialization functions at start time. The program @code{collect2} works by linking the program once and looking through the linker output file for symbols with particular names indicating they are constructor functions. If it finds any, it creates a new temporary @samp{.c} file containing a table of them, compiles it, and links the program a second time including that file. @findex __main @cindex constructors, automatic calls The actual calls to the constructors are carried out by a subroutine called @code{__main}, which is called (automatically) at the beginning of the body of @code{main} (provided @code{main} was compiled with GNU CC)@. Calling @code{__main} is necessary, even when compiling C code, to allow linking C and C++ object code together. (If you use @option{-nostdlib}, you get an unresolved reference to @code{__main}, since it's defined in the standard GCC library. Include @option{-lgcc} at the end of your compiler command line to resolve this reference.) The program @code{collect2} is installed as @code{ld} in the directory where the passes of the compiler are installed. When @code{collect2} needs to find the @emph{real} @code{ld}, it tries the following file names: @itemize @bullet @item @file{real-ld} in the directories listed in the compiler's search directories. @item @file{real-ld} in the directories listed in the environment variable @code{PATH}. @item The file specified in the @code{REAL_LD_FILE_NAME} configuration macro, if specified. @item @file{ld} in the compiler's search directories, except that @code{collect2} will not execute itself recursively. @item @file{ld} in @code{PATH}. @end itemize ``The compiler's search directories'' means all the directories where @code{gcc} searches for passes of the compiler. This includes directories that you specify with @option{-B}. Cross-compilers search a little differently: @itemize @bullet @item @file{real-ld} in the compiler's search directories. @item @file{@var{target}-real-ld} in @code{PATH}. @item The file specified in the @code{REAL_LD_FILE_NAME} configuration macro, if specified. @item @file{ld} in the compiler's search directories. @item @file{@var{target}-ld} in @code{PATH}. @end itemize @code{collect2} explicitly avoids running @code{ld} using the file name under which @code{collect2} itself was invoked. In fact, it remembers up a list of such names---in case one copy of @code{collect2} finds another copy (or version) of @code{collect2} installed as @code{ld} in a second place in the search path. @code{collect2} searches for the utilities @code{nm} and @code{strip} using the same algorithm as above for @code{ld}. --- NEW FILE: configfiles.texi --- @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, @c 1999, 2000, 2001, 2002 Free Software Foundation, Inc. @c This is part of the GCC manual. @c For copying conditions, see the file gcc.texi. @node Configuration Files @subsubsection Files Created by @code{configure} Here we spell out what files will be set up by @file{configure} in the @file{gcc} directory. Some other files are created as temporary files in the configuration process, and are not used in the subsequent build; these are not documented. @itemize @bullet @item @file{Makefile} is constructed from @file{Makefile.in}, together with the host and target fragments (@pxref{Fragments, , Makefile Fragments}) @file{t-@var{target}} and @file{x-@var{host}} from @file{config}, if any, and language Makefile fragments @file{@var{language}/Make-lang.in}. @item @file{auto-host.h} contains information about the host machine determined by @file{configure}. If the host machine is different from the build machine, then @file{auto-build.h} is also created, containing such information about the build machine. @item @file{config.status} is a script that may be run to recreate the current configuration. @item @file{configargs.h} is a header containing details of the arguments passed to @file{configure} to configure GCC, and of the thread model used. @item @file{cstamp-h} is used as a timestamp. @item @file{fixinc/Makefile} is constructed from @file{fixinc/Makefile.in}. @item @file{gccbug}, a script for reporting bugs in GCC, is constructed from @file{gccbug.in}. @item @file{intl/Makefile} is constructed from @file{intl/Makefile.in}. @item @file{mklibgcc}, a shell script to create a Makefile to build libgcc, is constructed from @file{mklibgcc.in}. @item If a language @file{config-lang.in} file (@pxref{Front End Config, , The Front End @file{config-lang.in} File}) sets @code{outputs}, then the files listed in @code{outputs} there are also generated. @end itemize The following configuration headers are created from the Makefile, using @file{mkconfig.sh}, rather than directly by @file{configure}. @file{config.h}, @file{hconfig.h} and @file{tconfig.h} all contain the @file{xm-@var{machine}.h} header, if any, appropriate to the host, build and target machines respectively, the configuration headers for the target, and some definitions; for the host and build machines, these include the autoconfigured headers generated by @file{configure}. The other configuration headers are determined by @file{config.gcc}. They also contain the typedefs for @code{rtx}, @code{rtvec} and @code{tree}. @itemize @bullet @item @file{config.h}, for use in programs that run on the host machine. @item @file{hconfig.h}, for use in programs that run on the build machine. @item @file{tconfig.h}, for use in programs and libraries for the target machine. @item @file{tm_p.h}, which includes the header @file{@var{machine}-protos.h} that contains prototypes for functions in the target @file{.c} file. FIXME: why is such a separate header necessary? @end itemize --- NEW FILE: configterms.texi --- @c Copyright (C) 2001, 2002 Free Software Foundation, Inc. @c This is part of the GCC manual. @c For copying conditions, see the file gcc.texi. @node Configure Terms @section Configure Terms and History @cindex configure terms @cindex canadian The configure and build process has a long and colorful history, and can be confusing to anyone who doesn't know why things are the way they are. While there are other documents which describe the configuration process in detail, here are a few things that everyone working on GCC should know. There are three system names that the build knows about: the machine you are building on (@dfn{build}), the machine that you are building for (@dfn{host}), and the machine that GCC will produce code for (@dfn{target}). When you configure GCC, you specify these with @option{--build=}, @option{--host=}, and @option{--target=}. Specifying the host without specifying the build should be avoided, as @command{configure} may (and once did) assume that the host you specify is also the build, which may not be true. If build, host, and target are all the same, this is called a @dfn{native}. If build and host are the same but target is different, this is called a @dfn{cross}. If build, host, and target are all different this is called a @dfn{canadian} (for obscure reasons dealing with Canada's political party and the background of the person working on the build at that time). If host and target are the same, but build is different, you are using a cross-compiler to build a native for a different system. Some people call this a @dfn{host-x-host}, @dfn{crossed native}, or @dfn{cross-built native}. If build and target are the same, but host is different, you are using a cross compiler to build a cross compiler that produces code for the machine you're building on. This is rare, so there is no common way of describing it (although I propose calling it a @dfn{crossback}). If build and host are the same, the GCC you are building will also be used to build the target libraries (like @code{libstdc++}). If build and host are different, you must have already build and installed a cross compiler that will be used to build the target libraries (if you configured with @option{--target=foo-bar}, this compiler will be called @command{foo-bar-gcc}). In the case of target libraries, the machine you're building for is the machine you specified with @option{--target}. So, build is the machine you're building on (no change there), host is the machine you're building for (the target libraries are built for the target, so host is the target you specified), and target doesn't apply (because you're not building a compiler, you're building libraries). The configure/make process will adjust these variables as needed. It also sets @code{$with_cross_host} to the original @option{--host} value in case you need it. The @code{libiberty} support library is built up to three times: once for the host, once for the target (even if they are the same), and once for the build if build and host are different. This allows it to be used by all programs which are generated in the course of the build process. --- NEW FILE: contrib.texi --- @c Copyright (C) 1988,1989,1992,1993,1994,1995,1996,1997,1998,1999,2000,2001,2002 @c Free Software Foundation, Inc. @c This is part of the GCC manual. @c For copying conditions, see the file gcc.texi. @node Contributors @unnumbered Contributors to GCC @cindex contributors The GCC project would like to thank its many contributors. Without them the project would not have been nearly as successful as it has been. Any omissions in this list are accidental. Feel free to contact @email{law@@redhat.com} if you have been left out or some of your contributions are not listed. Please keep this list in alphabetical order. Some projects operating under the GCC project maintain their own list of contributors, such as @uref{http://gcc.gnu.org/libstdc++/,the C++ library}. @itemize @bullet @item Analog Devices helped implement the support for complex data types and iterators. @item John David Anglin for improvements to libstdc++-v3 and the HP-UX port. @item James van Artsdalen wrote the code that makes efficient use of the Intel 80387 register stack. @item Alasdair Baird for various bugfixes. @item Gerald Baumgartner added the signature extension to the C++ front end. @item Neil Booth for various work on cpplib. @item Per Bothner for his direction via the steering committee and various improvements to our infrastructure for supporting new languages. Chill and Java front end implementations. Initial implementations of cpplib, fix-header, config.guess, libio, and past C++ library (libg++) maintainer. @item Devon Bowen helped port GCC to the Tahoe. @item Don Bowman for mips-vxworks contributions. @item Dave Brolley for work on cpplib and Chill. @item Robert Brown implemented the support for Encore 32000 systems. @item Christian Bruel for improvements to local store elimination. @item Herman A.J. ten Brugge for various fixes. @item Joe Buck for his direction via the steering committee. @item Craig Burley for leadership of the Fortran effort. @item Paolo Carlini for his work on libstdc++-v3. @item John Carr for his alias work, SPARC hacking, infrastructure improvements, previous contributions to the steering committee, loop optimizations, etc. @item Steve Chamberlain wrote the support for the Hitachi SH and H8 processors and the PicoJava processor. @item Scott Christley for his Objective-C contributions. @item Branko Cibej for more warning contributions. @item Nick Clifton for arm, mcore, fr30, v850, m32r work, @option{--help}, and other random hacking. @item Ralf Corsepius for SH testing and minor bugfixing. @item Stan Cox for care and feeding of the x86 port and lots of behind the scenes hacking. @item Alex Crain provided changes for the 3b1. @item Ian Dall for major improvements to the NS32k port. @item Dario Dariol contributed the four varieties of sample programs that print a copy of their source. @item Ulrich Drepper for his work on the C++ runtime libraries, glibc, testing of GCC using glibc, ISO C99 support, CFG dumping support, etc. @item Richard Earnshaw for his ongoing work with the ARM@. @item David Edelsohn for his direction via the steering committee, ongoing work with the RS6000/PowerPC port, and help cleaning up Haifa loop changes. @item Paul Eggert for random hacking all over GCC@. @item Mark Elbrecht for various DJGPP improvements. @item Ben Elliston for his work to move the Objective-C runtime into its own subdirectory and for his work on autoconf. @item Marc Espie for OpenBSD support. @item Doug Evans for much of the global optimization framework, arc, m32r, and SPARC work. @item Fred Fish for BeOS support and Ada fixes. @item Peter Gerwinski for various bugfixes and the Pascal front end. @item Kaveh Ghazi for his direction via the steering committee and amazing work to make @samp{-W -Wall} useful. @item Judy Goldberg for c++ contributions. @item Torbjorn Granlund for various fixes and the c-torture testsuite, multiply- and divide-by-constant optimization, improved long long support, improved leaf function register allocation, and his direction via the steering committee. @item Anthony Green for his @option{-Os} contributions and Java front end work. @item Michael K. Gschwind contributed the port to the PDP-11. @item Ron Guilmette implemented the @command{protoize} and @command{unprotoize} tools, the support for Dwarf symbolic debugging information, and much of the support for System V Release 4. He has also worked heavily on the Intel 386 and 860 support. @item Bruno Haible for improvements in the runtime overhead for EH, new warnings and assorted bugfixes. @item Andrew Haley for his Java work. @item Chris Hanson assisted in making GCC work on HP-UX for the 9000 series 300. @item Michael Hayes for various thankless work he's done trying to get the c30/c40 ports functional. Lots of loop and unroll improvements and fixes. @item Kate Hedstrom for staking the g77 folks with an initial testsuite. @item Richard Henderson for his ongoing SPARC, alpha, and ia32 work, loop opts, and generally fixing lots of old problems we've ignored for years, flow rewrite and lots of further stuff, including reviewing tons of patches. @item Nobuyuki Hikichi of Software Research Associates, Tokyo, contributed the support for the Sony NEWS machine. @item Manfred Hollstein for his ongoing work to keep the m88k alive, lots of testing an bugfixing, particularly of our configury code. @item Steve Holmgren for MachTen patches. @item Jan Hubicka for his x86 port improvements. @item Christian Iseli for various bugfixes. @item Kamil Iskra for general m68k hacking. @item Lee Iverson for random fixes and MIPS testing. @item Andreas Jaeger for various fixes to the MIPS port @item Jakub Jelinek for his SPARC work and sibling call optimizations as well as lots of bug fixes and test cases. @item Janis Johnson for ia64 testing and fixes and for her quality improvement sidetracks. @item J. Kean Johnston for OpenServer support. @item Klaus Kaempf for his ongoing work to make alpha-vms a viable target. @item David Kashtan of SRI adapted GCC to VMS@. @item Geoffrey Keating for his ongoing work to make the PPC work for GNU/Linux and his automatic regression tester. @item Brendan Kehoe for his ongoing work with g++. @item Oliver M. Kellogg of Deutsche Aerospace contributed the port to the MIL-STD-1750A@. @item Richard Kenner of the New York University Ultracomputer Research Laboratory wrote the machine descriptions for the AMD 29000, the DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the support for instruction attributes. He also made changes to better support RISC processors including changes to common subexpression elimination, strength reduction, function calling sequence handling, and condition code support, in addition to generalizing the code for frame pointer elimination and delay slot scheduling. Richard Kenner was also the head maintainer of GCC for several years. @item Mumit Khan for various contributions to the cygwin and mingw32 ports and maintaining binary releases for Windows hosts. @item Robin Kirkham for cpu32 support. @item Mark Klein for PA improvements. @item Thomas Koenig for various bugfixes. @item Bruce Korb for the new and improved fixincludes code. @item Benjamin Kosnik for his g++ work and for leading the libstdc++-v3 effort. @item Charles LaBrec contributed the support for the Integrated Solutions 68020 system. @item Jeff Law for his direction via the steering committee, coordinating the entire egcs project and GCC 2.95, rolling out snapshots and releases, handling merges from GCC2, reviewing tons of patches that might have fallen through the cracks else, and random but extensive hacking. @item Marc Lehmann for his direction via the steering committee and helping with analysis and improvements of x86 performance. @item Ted Lemon wrote parts of the RTL reader and printer. @item Kriang Lerdsuwanakij for improvements to demangler and various c++ fixes. @item Warren Levy major work on libgcj (Java Runtime Library) and random work on the Java front end. @item Alain Lichnewsky ported GCC to the MIPS CPU. @item Robert Lipe for OpenServer support, new testsuites, testing, etc. @item Weiwen Liu for testing and various bugfixes. @item Dave Love for his ongoing work with the Fortran front end and runtime libraries. @item Martin von L@"owis for internal consistency checking infrastructure, and various C++ improvements including namespace support. @item H.J. Lu for his previous contributions to the steering committee, many x86 bug reports, prototype patches, and keeping the GNU/Linux ports working. @item Greg McGary for random fixes and (someday) bounded pointers. @item Andrew MacLeod for his ongoing work in building a real EH system, various code generation improvements, work on the global optimizer, etc. @item Vladimir Makarov for hacking some ugly i960 problems, PowerPC hacking improvements to compile-time performance and overall knowledge and direction in the area of instruction scheduling. @item Bob Manson for his behind the scenes work on dejagnu. @item Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, powerpc, haifa, ECOFF debug support, and other assorted hacking. @item Jason Merrill for his direction via the steering committee and leading the g++ effort. @item David Miller for his direction via the steering committee, lots of SPARC work, improvements in jump.c and interfacing with the Linux kernel developers. @item Gary Miller ported GCC to Charles River Data Systems machines. @item Mark Mitchell for his direction via the steering committee, mountains of C++ work, load/store hoisting out of loops, alias analysis improvements, ISO C @code{restrict} support, and serving as release manager for GCC 3.x. @item Alan Modra for various GNU/Linux bits and testing. @item Toon Moene for his direction via the steering committee, Fortran maintenance, and his ongoing work to make us make Fortran run fast. @item Jason Molenda for major help in the care and feeding of all the services on the gcc.gnu.org (formerly egcs.cygnus.com) machine---mail, web services, ftp services, etc etc. @item Catherine Moore for fixing various ugly problems we have sent her way, including the haifa bug which was killing the Alpha & PowerPC Linux kernels. @item David Mosberger-Tang for various Alpha improvements. @item Stephen Moshier contributed the floating point emulator that assists in cross-compilation and permits support for floating point numbers wider than 64 bits and for ISO C99 support. @item Bill Moyer for his behind the scenes work on various issues. @item Philippe De Muyter for his work on the m68k port. @item Joseph S. Myers for his work on the PDP-11 port, format checking and ISO C99 support, and continuous emphasis on (and contributions to) documentation. @item Nathan Myers for his work on libstdc++-v3. @item NeXT, Inc.@: donated the front end that supports the Objective-C language. @item Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the search engine setup, various documentation fixes and other small fixes. @item Geoff Noer for this work on getting cygwin native builds working. @item David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related infrastructure improvements. @item Alexandre Oliva for various build infrastructure improvements, scripts and amazing testing work. @item Melissa O'Neill for various NeXT fixes. @item Rainer Orth for random MIPS work, including improvements to our o32 ABI support, improvements to dejagnu's MIPS support, etc. @item Paul Petersen wrote the machine description for the Alliant FX/8. @item Alexandre Petit-Bianco for his Java work. @item Matthias Pfaller for major improvements to the NS32k port. @item Gerald Pfeifer for his direction via the steering committee, pointing out lots of problems we need to solve, maintenance of the web pages, and taking care of documentation maintenance in general. @item Ovidiu Predescu for his work on the Objective-C front end and runtime libraries. @item Ken Raeburn for various improvements to checker, MIPS ports and various cleanups in the compiler. @item David Reese of Sun Microsystems contributed to the Solaris on PowerPC port. @item Gabriel Dos Reis for contributions and maintenance of libstdc++-v3, including valarray implementation and limits support. @item Joern Rennecke for maintaining the sh port, loop, regmove & reload hacking. @item Loren J. Rittle for improvements to libstdc++-v3 and the FreeBSD port. @item Craig Rodrigues for processing tons of bug reports. @item Gavin Romig-Koch for lots of behind the scenes MIPS work. @item Ken Rose for fixes to our delay slot filling code. @item Paul Rubin wrote most of the preprocessor. @item Juha Sarlin for improvements to the H8 code generator. @item Greg Satz assisted in making GCC work on HP-UX for the 9000 series 300. @item Peter Schauer wrote the code to allow debugging to work on the Alpha. @item William Schelter did most of the work on the Intel 80386 support. @item Bernd Schmidt for various code generation improvements and major work in the reload pass as well a serving as release manager for GCC 2.95.3. @item Andreas Schwab for his work on the m68k port. @item Joel Sherrill for his direction via the steering committee, RTEMS contributions and RTEMS testing. @item Nathan Sidwell for many C++ fixes/improvements. @item Jeffrey Siegal for helping RMS with the original design of GCC, some code which handles the parse tree and RTL data structures, constant folding and help with the original VAX & m68k ports. @item Franz Sirl for his ongoing work with making the PPC port stable for linux. @item Andrey Slepuhin for assorted AIX hacking. @item Christopher Smith did the port for Convex machines. @item Randy Smith finished the Sun FPA support. @item Scott Snyder for various fixes. @item Richard Stallman, for writing the original gcc and launching the GNU project. @item Jan Stein of the Chalmers Computer Society provided support for Genix, as well as part of the 32000 machine description. @item Nigel Stephens for various mips16 related fixes/improvements. @item Jonathan Stone wrote the machine description for the Pyramid computer. @item Graham Stott for various infrastructure improvements. @item Mike Stump for his Elxsi port, g++ contributions over the years and more recently his vxworks contributions @item Shigeya Suzuki for this fixes for the bsdi platforms. @item Ian Lance Taylor for his mips16 work, general configury hacking, fixincludes, etc. @item Holger Teutsch provided the support for the Clipper CPU. @item Gary Thomas for his ongoing work to make the PPC work for GNU/Linux. @item Philipp Thomas for random bugfixes throughout the compiler @item Kresten Krab Thorup wrote the run time support for the Objective-C language. @item Michael Tiemann for random bugfixes, the first instruction scheduler, initial C++ support, function integration, NS32k, SPARC and M88k machine description work, delay slot scheduling. @item Teemu Torma for thread safe exception handling support. @item Leonard Tower wrote parts of the parser, RTL generator, and RTL definitions, and of the VAX machine description. @item Tom Tromey for internationalization support and his Java work. @item Lassi Tuura for improvements to config.guess to determine HP processor types. @item Todd Vierling for contributions for NetBSD ports. @item Dean Wakerley for converting the install documentation from HTML to texinfo in time for GCC 3.0. @item Krister Walfridsson for random bugfixes. @item John Wehle for various improvements for the x86 code generator, related infrastructure improvements to help x86 code generation, value range propagation and other work, WE32k port. @item Zack Weinberg for major work on cpplib and various other bugfixes. @item Dale Wiles helped port GCC to the Tahoe. @item Bob Wilson from Tensilica, Inc.@: for the Xtensa port. @item Jim Wilson for his direction via the steering committee, tackling hard problems in various places that nobody else wanted to work on, strength reduction and other loop optimizations. @item Carlo Wood for various fixes. @item Tom Wood for work on the m88k port. @item Masanobu Yuhara of Fujitsu Laboratories implemented the machine description for the Tron architecture (specifically, the Gmicro). @item Kevin Zachmann helped ported GCC to the Tahoe. @end itemize We'd also like to thank the folks who have contributed time and energy in testing GCC: @itemize @bullet @item David Billinghurst @item Horst von Brand @item Rodney Brown @item Joe Buck @item Craig Burley @item Ulrich Drepper @item David Edelsohn @item Yung Shing Gene @item Kaveh Ghazi @item Kate Hedstrom @item Richard Henderson @item Manfred Hollstein @item Kamil Iskra @item Christian Joensson @item Jeff Law @item Robert Lipe @item Damon Love @item Dave Love @item H.J. Lu @item Brad Lucier @item Mumit Khan @item Matthias Klose @item Martin Knoblauch @item David Miller @item Toon Moene @item Matthias Mueller @item Alexandre Oliva @item Richard Polton @item David Rees @item Loren J. Rittle @item Peter Schmid @item David Schuler @item Vin Shelton @item Franz Sirl @item Mike Stump @item Carlo Wood @item And many others @end itemize And finally we'd like to thank everyone who uses the compiler, submits bug reports and generally reminds us why we're doing this work in the first place. --- NEW FILE: contribute.texi --- @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, @c 1999, 2000, 2001 Free Software Foundation, Inc. @c This is part of the GCC manual. @c For copying conditions, see the file gcc.texi. @node Contributing @chapter Contributing to GCC Development If you would like to help pretest GCC releases to assure they work well, our current development sources are available by CVS (see @uref{http://gcc.gnu.org/cvs.html}). Source and binary snapshots are also available for FTP; see @uref{http://gcc.gnu.org/snapshots.html}. If you would like to work on improvements to GCC, please read the advice at these URLs: @smallexample @uref{http://gcc.gnu.org/contribute.html} @uref{http://gcc.gnu.org/contributewhy.html} @end smallexample @noindent for information on how to make useful contributions and avoid duplication of effort. Suggested projects are listed at @uref{http://gcc.gnu.org/projects/}. --- NEW FILE: copying-lib.texi --- @node Library Copying @appendixsec GNU LESSER GENERAL PUBLIC LICENSE @cindex LGPL, Lesser General Public License @center Version 2.1, February 1999 @display Copyright @copyright{} 1991, 1999 Free Software Foundation, Inc. 59 Temple Place -- Suite 330, Boston, MA 02111-1307, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] @end display @appendixsubsec Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software---to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software---typically libraries---of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your... [truncated message content] |