<html> <head> <title>GCC Frequently Asked Questions</title> </head> <body> <h1 align="center">GCC Frequently Asked Questions</h1> <p>The latest version of this document is always available at <a href=" http://www.gnu.org/software/gcc/faq.html">http://www.gnu.org/software/gcc/faq.html</a>.</p> <p>This FAQ tries to answer specific questions concerning GCC. For general information regarding C, C++, resp. Fortran please check the <a href="http://www.eskimo.com/~scs/C-faq/top.html">comp.lang.c FAQ</a>, <a href="http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/"> comp.lang.c++ FAQ</a>, <a href="http://reality.sgi.com/austern_mti/std-c++/faq.html"> comp.std.c++ FAQ</a>, and the <a href="http://www.fortran.com/fortran/info.html">Fortran Information page</a>.</p> <hr> <h1>Questions</h1> <ol> <li><a href="#general">General information</a> <ol> <li><a href="#gcc">What is the relationship between GCC and EGCS</a></li> <li><a href="#cygnus">What is the relationship between GCC and Cygnus</a></li> <li><a href="#open-development">What is an open development model?</a></li> <li><a href="#bugreport">How to report bugs</a></li> <li><a href="#support">How do I get a bug fixed or a feature added?</a></li> </ol></li> <li><a href="#installation">Installation</a> <ol> <li><a href="#fortran">Problems building the Fortran compiler</a></li> <li><a href="#multiple">How to install multiple versions of GCC</a></li> <li><a href="#rpath">Dynamic linker is unable to find GCC libraries</a></li> <li><a href="#rpath">libstdc++/libio tests fail badly with --enable-shared</a></li> <li><a href="#gas">GCC can not find GNU as/GNU ld</a></li> <li><a href="#environ">cpp: Usage:... Error</a></li> </ol></li> <li><a href="#testsuite">Testsuite problems</a> <ol> <li><a href="#testsuite">Why is there no testsuite in GCC 2.95</a></li> <li><a href="#dejagnu">Unable to run the testsuite</a></li> <li><a href="#testoptions">How do I pass flags like <code>-fnew-abi</code> to the testsuite?</a></li> <li><a href="#multipletests">How can I run the test suite with multiple options?</a></li> </ol></li> <li><a href="#platform">Platform-specific issues</a> <ol> <li><a href="#x86eh">Problems with exception handling on x86 platforms</a></li> <li><a href="#asmclobber">Problems with <tt>Invalid `asm' statement</tt>s</a></li> <li><a href="#linuxkernel">Building Linux kernels</a> </li> <li><a href="#X11R6">How do I compile X11 headers with g++</a> </li> <li><a href="#cross">How to build a cross compiler</a></li> </ol></li> <li><a href="#bugs">Bugs and Non-Bugs</a> <ol> <li><a href="#fdzero">FD_ZERO macro</a></li> <li><a href="#octave">Octave 2.0.13 does not compile</a></li> <li><a href="#stdin">Why can't I initialize a static variable with <tt>stdin</tt>?</a></li> <li><a href="#macarg">Why can't I use #if here?</a></li> </ol></li> <li><a href="#misc">Miscellaneous</a> <ol> <li><a href="#memexhausted">Virtual memory exhausted</a></li> <li><a href="#snapshot">Snapshots, how, when, why</a></li> <li><a href="#friend">Friend Templates</a></li> <li><a href="#libg++">Where to find libg++</a></li> <li><a href="#generated_files">Why do I need autoconf, bison, xgettext, automake, etc </a></li> <li><a href="#gdb">Problems debugging GCC code</a></li> <li><a href="#conflicts">Conflicts when using cvs update </a></li> <li><a href="#gnat">Using GCC with GNAT/Ada</a></li> <li><a href="#gpc">Using GCC with GNU Pascal</a></li> <li><a href="#cvssnapshots">Using CVS to download snapshots </a></li> <li><a href="#picflag-needed">Why can't I build a shared library?</a></li> <li><a href="spam.html">Dealing with spam on the lists</a></li> <li><a href="#squangle">How to work around too long C++ symbol names? (<tt>-fsquangle</tt>)</a></li> <li><a href="#gperf">When building from CVS sources, I see 'gperf: invalid option -- F', even with the most current version of gperf.</a></li> <li><a href="#vtables">When building C++, the linker says my constructors, destructors or virtual tables are undefined, but I defined them</a></li> <li><a href="#libstdc++">What is libstdc++-v3 and how can I use it with g++?</a></li> </ol></li> </ol> <hr> <a name="general"></a> <h1>General information</h1> <h2><a name="gcc">What is the relationship between GCC and EGCS</a></h2> <p>In 1990/1991 gcc version 1 had reached a point of stability. For the targets it could support, it worked well. It had limitations inherent in its design that would be difficult to resolve, so a major effort was made to resolve those limitiations and gcc version 2 was the result.</p> <p>When we had gcc2 in a useful state, development efforts on gcc1 stopped and we all concentrated on making gcc2 better than gcc1 could ever be. This is the kind of step forward we wanted to make with the EGCS project when it was formed in 1997.</p> <p>In April 1999 the Free Software Foundation officially halted development on the gcc2 compiler and appointed the EGCS project as the official GCC maintainers.</p> <p>We are in the process of merging GCC and EGCS, which will take some time. The net result will be a single project which will carry forward GCC development under the ultimate control of the <a href="steering.html">GCC Steering Committee</a>.</p> <hr> <h2><a name="cygnus">What is the relationship between GCC and Cygnus</a></h2> <p>It is a common mis-conception that Cygnus controls either directly or indirectly GCC.</p> <p>While Cygnus does donate hardware, network connections, code and developer time to GCC development, Cygnus does not control GCC. <p>Overall control of GCC is in the hands of the <a href="steering.html">GCC Steering Committee</a> which includes people from a variety of different organizations and backgrounds. The purpose of the steering committee is to make decisions in the best interest of GCC and to help ensure that no individual or company has control over the project.</p> <p>To summarize, Cygnus contributes to GCCproject, but does not exert a controlling influence over GCC.</p> <hr> <h2><a name="open-development">What is an open development model?</a></h2> <p>With GCC, we are going to try a bazaar style<a href="#cathedral-vs-bazaar"><b>[1]</b></a> approach to its development: We make snapshots publicly available to anyone who wants to try them; we're going to welcome anyone to join the development mailing list. All of the discussions on the development mailing list are available via the web. We're going to be making releases with a much higher frequency than they have been made in the past.</p> <p>In addition to weekly snapshots of the GCC development sources, we have the sources readable from a CVS server by anyone. Furthermore we are using remote CVS to allow remote maintainers write access to the sources.</p> <p>There have been many potential gcc developers who were not able to participate in gcc development in the past. We want these people to help in any way they can; we ultimately want GCC to be the best compiler in the world.</p> <p>A compiler is a complicated piece of software, there will still be strong central maintainers who will reject patches, who will demand documentation of implementations, and who will keep the level of quality as high as it is today. Code that could use wider testing may be integrated--code that is simply ill-conceived won't be.</p> <p>GCC is not the first piece of software to use this open development process; FreeBSD, the Emacs lisp repository, and the Linux kernel are a few examples of the bazaar style of development.</p> <p>With GCC, we will be adding new features and optimizations at a rate that has not been done since the creation of gcc2; these additions will inevitably have a temporarily destabilizing effect. With the help of developers working together with this bazaar style development, the resulting stability and quality levels will be better than we've had before.</p> <blockquote> <a name="cathedral-vs-bazaar"><b>[1]</b></a> We've been discussing different development models a lot over the past few months. The paper which started all of this introduced two terms: A <b>cathedral</b> development model versus a <b>bazaar</b> development model. The paper is written by Eric S. Raymond, it is called ``<a href="http://locke.ccil.org/~esr/writings/cathedral.html">The Cathedral and the Bazaar</a>''. The paper is a useful starting point for discussions. </blockquote> <hr> <h2><a name="bugreport">How to report bugs</a></h2> <p>There are complete instructions in the <a href="onlinedocs/">gcc info manual</a>, section Bugs. The manual can also be read using `<i>M-x <tt>info</tt></i>' in Emacs, or if the GNU <tt>info</tt> program is installed on your system by `<tt>info --node "(gcc)Bugs"</tt>'. Or see the file <a href="http://egcs.cygnus.com/cgi-bin/cvsweb.cgi/~checkout~/egcs/gcc/BUGS?content-type=text/plain&only_with_tag=HEAD">BUGS</a> included with the GCC source code.</p> <p>Before you report a bug for the <em>C++ compiler</em>, please check the <a href="bugs.html">list of well-known bugs</a>. If you want to report a bug with <em>egcs 1.0.x</em> or <em>egcs 1.1.x</em>, we strongly recommend upgrading to the current release first.</p> <p>In short, if GCC says <tt>Internal compiler error</tt> (or any other error that you'd like us to be able to reproduce, for that matter), please mail a bug report to <a href="mailto:gcc-bugs@gcc.gnu.org">gcc-bugs@gcc.gnu.org</a> or <a href="mailto:bug-gcc@gnu.org">bug-gcc@gnu.org</a> including:</p> <ul> <li>The GCC version</li> <li>The system type</li> <li>All options you passed to the compiler</li> <li>Preprocessed output of the source file that caused the compiler error</li> </ul> <p>All this can normally be accomplished by mailing the command line, the output of the command, and the resulting `<tt><i>your-file</i>.i</tt>' for C, or `<tt><i>your-file</i>.ii</tt>' for C++, corresponding to:</p> <p><tt>gcc -v --save-temps <i>all-your-options</i> <i>your-file</i>.c</tt></p> <p>Typically the CPP output (extension <code>.i</code> for C or <code>.ii</code> for C++) will be large, so please compress the resulting file with one of the popular compression programs such as <tt>bzip2</tt>, <tt>gzip</tt>, <tt>zip</tt>, <tt>pkzip</tt> or <tt>compress</tt> (in decreasing order of preference). Use maximum compression (<code>-9</code>) if available. Please include the compressed CPP output in your bug report.</p> <p>Since we're supposed to be able to re-create the assembly output (extension <code>.s</code>), you usually don't have to include it in the bug report, although you may want to post parts of it to point out assembly code you consider to be wrong.</p> <p>Whether to use MIME attachments or <code>uuencode</code> is up to you. In any case, make sure the compiler command line, version and error output are in plain text, so that we don't have to decode the bug report in order to tell who should take care of it. A meaningful subject indicating language and platform also helps.</p> <p>The gcc lists have message size limits (100 kbytes) and bug reports over those limits will currently be bounced. We're trying to find a way to allow larger bug reports to be posted, but this is currently impossible (unless you use MIME partials, which most people are unable to handle anyway, so you'd better avoid them for now). So, although we prefer to have complete bug reports archived, if you cannot reduce the bug report below the limit, please make it available for ftp or http and post the URL. Another alternative is to break the preprocessed output in multiple files (using <code>split</code>, for example) and post them in separate messages, but we prefer to have self-contained bug reports in single messages.</p> <p>If you fail to supply enough information for a bug report to be reproduced, someone will probably ask you to post additional information (or just ignore your bug report, if they're in a bad day, so try to get it right on the first posting :-). In this case, please post the additional information to the bug reporting mailing list, not just to the person who requested it, unless explicitly told so. If possible, please include in this follow-up all the information you had supplied in the incomplete bug report (including the preprocessor output), so that the new bug report is self-contained.</p> <hr> <h2><a name="support">How do I get a bug fixed or a feature added?</a></h2> <p>There are lots of ways to get something fixed. The list below may be incomplete, but it covers many of the common cases. These are listed roughly in order of increasing difficulty for the average GCC user, meaning someone who is not skilled in the internals of GCC, and where difficulty is measured in terms of the time required to fix the bug. No alternative is better than any other; each has it's benefits and disadvantages.</p> <ul> <li>Hire someone to fix it for you. There are various companies and individuals providing support for GCC. This alternative costs money, but is relatively likely to get results.</li> <li>Report the problem to gcc-bugs and hope that someone will be kind enough to fix it for you. While this is certainly possible, and often happens, there is no guarantee that it will. You should not expect the same response from gcc-bugs that you would see from a commercial support organization since the people who read gcc-bugs, if they choose to help you, will be volunteering their time. This alternative will work best if you follow the directions on <a href="#bugreport">submitting bugreports</a>.</li> <li>Fix it yourself. This alternative will probably bring results, if you work hard enough, but will probably take a lot of time, and, depending on the quality of your work and the perceived benefits of your changes, your code may or may not ever make it into an official release of GCC.</li> </ul> <hr> <a name="installation"></a> <h1>Installation</h1> <h2><a name="fortran">Problems building the Fortran compiler</a></h2> <p>The Fortran front end can not be built with most vendor compilers; it must be built with gcc. As a result, you may get an error if you do not follow the install instructions carefully.</p> <p>In particular, instead of using "make" to build GCC, you should use "make bootstrap" if you are building a native compiler or "make cross" if you are building a cross compiler.</p> <p>It has also been reported that the Fortran compiler can not be built on Red Hat 4.X GNU/Linux for the Alpha. Fixing this may require upgrading binutils or to Red Hat 5.0; we'll provide more information as it becomes available.</p> <hr> <h2><a name="multiple">How to install multiple versions of gcc</a></h2> <p>It may be desirable to install multiple versions of the compiler on the same system. This can be done by using different prefix paths at configure time and a few symlinks.</p> <p>Basically, configure the two compilers with different --prefix options, then build and install each compiler. Assume you want "gcc" to be the latest compiler and available in /usr/local/bin; also assume that you want "gcc2" to be the older gcc2 compiler and also available in /usr/local/bin.</p> <p>The easiest way to do this is to configure the new GCC with --prefix=/usr/local/gcc and the older gcc2 with --prefix=/usr/local/gcc2. Build and install both compilers. Then make a symlink from /usr/local/bin/gcc to /usr/local/gcc/bin/gcc and from /usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar links for the "g++", "c++" and "g77" compiler drivers.</p> <p>An alternative to using symlinks is to configure with a --program-transform-name option. This option specifies a sed command to process installed program names with. Using it you can, for instance, have all the new GCC programs installed as "new-gcc" and the like. You will still have to specify different --prefix options for new GCC and old GCC, because it is only the executable program names that are transformed. The difference is that you (as administrator) do not have to set up symlinks, but must specify additional directories in your (as a user) PATH. A complication with --program-transform-name is that the sed command invariably contains characters significant to the shell, and these have to be escaped correctly, also it is not possible to use "^" or "$" in the command. Here is the option to prefix "new-" to the new GCC installed programs "--program-transform-name='s,\\\\(.*\\\\),new-\\\\1,'". With the above --prefix option, that will install the new GCC programs into /usr/local/gcc/bin with names prefixed by "new-". You can use --program-transform-name if you have multiple versions of GCC, and wish to be sure about which version you are invoking.</p> <p>If you use --prefix, GCC may have difficulty locating a GNU assembler or linker on your system, <a href="#gas">GCC can not find GNU as/GNU ld</a> explains how to deal with this.</p> <hr> <h2><a name="rpath">Dynamic linker is unable to find GCC libraries</a></h2> <p>This problem manifests itself by programs not finding shared libraries they depend on when the programs are started. Note this problem often manifests itself with failures in the libio/libstdc++ tests after configuring with --enable-shared and building GCC.</p> <p>GCC does not specify a runpath so that the dynamic linker can find dynamic libraries at runtime.</p> <p>The short explanation is that if you always pass a -R option to the linker, then your programs become dependent on directories which may be NFS mounted, and programs may hang unnecessarily when an NFS server goes down.</p> <p>The problem is not programs that do require the directories; those programs are going to hang no matter what you do. The problem is programs that do not require the directories.</p> <p>SunOS effectively always passed a -R option for every -L option; this was a bad idea, and so it was removed for Solaris. We should not recreate it.</p> <p>However, if you feel you really need such an option to be passed automatically to the linker, you may add it to the gcc specs file. This file can be found in the same directory that contains cc1 (run <code>gcc -print-prog-name=cc1</code> to find it). You may add linker flags such as <code>-R</code> or <code>-rpath</code>, depending on platform and linker, to the <code>*link</code> or <code>*lib</code> specs.</p> <p>Another alterative is to install a wrapper script around gcc, g++ or ld that adds the appropriate directory to the environment variable <code>LD_RUN_PATH</code> or equivalent (again, it's platform-dependent).</p> <p>Yet another option, that works on a few platforms, is to hard-code the full pathname of the library into its soname. This can only be accomplished by modifying the appropriate <tt>.ml</tt> file within <tt>libstdc++/config</tt> (and also <tt>libg++/config</tt>, if you are building libg++), so that <code>$(libdir)/</code> appears just before the library name in <code>-soname</code> or <code>-h</code> options.</p> <hr> <h2><a name="gas">GCC can not find GNU as/GNU ld</a></h2> <p>GCC searches the PATH for an assembler and a loader, but it only does so after searching a directory list hard-coded in the gcc executables. Since, on most platforms, the hard-coded list includes directories in which the system asembler and loader can be found, you may have to take one of the following actions to arrange that gcc uses the GNU versions of those programs.</p> <p>To ensure that GCC finds the GNU assembler (the GNU loader), which are required by <a href="install/specific.html">some configurations</A>, you should configure these with the same --prefix option as you used for GCC. Then build & install GNU as (GNU ld) and proceed with building GCC.</p> <p>Another alternative is to create links to GNU as and ld in any of the directories printed by the command `<tt>gcc -print-search-dirs | grep '^programs:'</tt>'. The link to `<tt>ld</tt>' should be named `<tt>real-ld</tt>' if `<tt>ld</tt>' already exists. If such links do not exist while you're compiling GCC, you may have to create them in the build directories too, within the <tt>gcc</tt> directory <em>and</em> in all the <tt>gcc/stage*</tt> subdirectories.</p> <p>GCC 2.95 allows you to specify the full pathname of the assembler and the linker to use. The configure flags are `<tt>--with-as=/path/to/as</tt>' and `<tt>--with-ld=/path/to/ld</tt>'. GCC will try to use these pathnames before looking for `<tt>as</tt>' or `<tt>(real-)ld</tt>' in the standard search dirs. If, at configure-time, the specified programs are found to be GNU utilities, `<tt>--with-gnu-as</tt>' and `<tt>--with-gnu-ld</tt>' need not be used; these flags will be auto-detected. One drawback of this option is that it won't allow you to override the search path for assembler and linker with command-line options <tt>-B/path/</tt> if the specified filenames exist.</p> <hr> <h2><a name="environ">cpp: Usage:... Error</a></h2> <p>If you get an error like this when building GCC (particularly when building __mulsi3), then you likely have a problem with your environment variables.</p> <pre> cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp [switches] input output </pre> <p>First look for an explicit '.' in either LIBRARY_PATH or GCC_EXEC_PREFIX from your environment. If you do not find an explicit '.', look for an empty pathname in those variables. Note that ':' at either the start or end of these variables is an implicit '.' and will cause problems.</p> <p>Also note '::' in these paths will also cause similar problems.</p> <hr> <a name="testsuite"></a> <h1>Testsuite problems</h1> <h2><a name="testsuite">Why is there no testsuite in GCC 2.95</a></h2> <p>The GCC testsuite is not included in the GCC 2.95 release due to the uncertain copyright status of some tests.</p> <p>The GCC team will be reviewing the entire testsuite to find and remove any tests with uncertain copyright status. Once those tests are removed from the testsuite, the testsuite as a whole will be copyrighted under the terms of the GPL and included in future GCC releases.</p> <p>It is believed that only a few tests have uncertain copyright status and thus only a few tests will need to be removed from the testsuite.</p> <hr> <h2><a name="dejagnu">Unable to run the testsuite</a></h2> <p>If you get a message about unable to find "standard.exp" when trying to run the GCC testsuites, then your dejagnu is too old to run the GCC tests. You will need to get a newer version of dejagnu; we've made a <a href="ftp://egcs.cygnus.com/pub/egcs/infrastructure/dejagnu-19981026.tar.gz"> dejagnu snapshot</a> available until a new version of dejagnu can be released.</p> <hr> <h2><a name="testoptions">How do I pass flags like <code>-fnew-abi</code> to the testsuite?</a></h2> <p>If you invoke <code>runtest</code> directly, you can use the <code>--tool_opts</code> option, e.g:</p> <pre> runtest --tool_opts "-fnew-abi -fno-honor-std" <other options> </pre> <p>Or, if you use <code>make check</code> you can use the <code>make</code> variable <code>RUNTESTFLAGS</code>, e.g:</p> <pre> make RUNTESTFLAGS='--tool_opts "-fnew-abi -fno-honor-std"' check-g++ </pre> <hr> <h2><a name="multipletests"> How can I run the test suite with multiple options? </a></h2> <p>If you invoke <code>runtest</code> directly, you can use the <code>--target_board</code> option, e.g:</p> <pre> runtest --target_board "unix{-fPIC,-fpic,}" <other options> </pre> <p>Or, if you use <code>make check</code> you can use the <code>make</code> variable <code>RUNTESTFLAGS</code>, e.g:</p> <pre> make RUNTESTFLAGS='--target_board "unix{-fPIC,-fpic,}"' check-gcc </pre> <p>Either of these examples will run the tests three times. Once with <code>-fPIC</code>, once with <code>-fpic</code>, and once with no additional flags.</p> <p>This technique is particularly useful on multilibbed targets.</p> <hr> <a name="platform"></a> <h1>Platform-specific issues</h1> <p>Please read the <a href="install/specific.html">host/target specific installation</a> notes, too.</p> <h2><a name="x86eh">Problems with exception handling on x86 platforms</a></h2> <p>If you are using the GNU assembler (aka gas) on an x86 platform and exception handling is not working correctly, then odds are you're using a buggy assembler. Releases of binutils prior to 2.9 are known to assemble exception handling code incorrectly.</p> <p>We recommend binutils-2.9.1 or newer. Some post-2.9.1 snapshots of binutils fix some subtle bugs, particularly on x86 and alpha. They are available at <a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/"> ftp://tsx-11.mit.edu/pub/linux/packages/GCC/</A>. The 2.9.1.0.15 snapshot is known to work fine on those platforms; other than that, be aware that snapshots are in general untested and may not work (or even build). Use them at your own risk.</p> <hr> <h2><a name="asmclobber">Problems with invalid `asm' statements</a></h2> <p>Previous releases of GCC (for example, GCC 2.7.2 or EGCS 1.1.2) did not detect as invalid a clobber specifier that clobbered an operand. Instead, it could spuriously and silently generate incorrect code for certain non-obvious cases of source code. Even more unfortunately, the manual (Using and Porting GCC, section Extended Asm, see the <a href="#bugreport"> bug report entry</a>) did not explicitly say that it was invalid to specify clobber registers that were destined to overlap operands; it could arguably be interpreted that it was correct to clobber an input operand to mark it as not holding a usable value after the asm.</p> <p>For the general case, there is no way to tell whether a specified clobber is <i>intended</i> to overlap with a specific (input) operand or is a program error, where the choice of actual register for operands failed to <i>avoid</i> the clobbered register. Such unavoidable overlap is detected by versions GCC 2.95 and newer, and flagged as an error rather than accepted. An error message is given, such as:</p> <pre> foo.c: In function `foo': foo.c:7: Invalid `asm' statement: foo.c:7: fixed or forbidden register 0 (ax) was spilled for class AREG. </pre> <p>Unfortunately, a lot of existing software, for example the <a href="#linuxkernel">Linux kernel</a> version 2.0.35 for the Intel x86, has constructs where input operands are marked as clobbered.</p> <p>The manual now describes how to write constructs with operands that are modified by the construct, but not actually used. To write an asm which modifies an input operand but does not output anything usable, specify that operand as an <b>output operand</b> outputting to an <b>unused dummy variable</b>.</p> <p>In the following example for the x86 architecture (taken from the Linux 2.0.35 kernel -- <tt>include/asm-i386/delay.h</tt>), the register-class constraint <tt>"a"</tt> denotes a register class containing the single register <tt>"ax"</tt> (aka. <tt>"eax"</tt>). It is therefore invalid to clobber <tt>"ax"</tt>; this operand has to be specified as an output as well as an input. The following code is therefore <b>invalid</b>:</p> <pre> extern __inline__ void __delay (int loops) { __asm__ __volatile__ (".align 2,0x90\n1:\tdecl %0\n\tjns 1b" : /* no outputs */ : "a" (loops) : "ax"); } </pre> <p>It could be argued that since the register class for <tt>"a"</tt> contains only a single register, this could be detected as an "obvious" intended clobber of the input operand. While that is feasible, it opens up for further "obvious" cases, where the level of obviousness changes from person to person. As there is a correct way to write such asm constructs, this obviousness-detection is not needed other than for reasons of compatibility with an existing code-base, and that code base can be corrected.</p> <p>This corrected and clobber-less version, is <b>valid</b> for GCC 2.95 as well as for previous versions of GCC and EGCS:</p> <pre> extern __inline__ void __delay (int loops) { int dummy; __asm__ __volatile__ (".align 2,0x90\n1:\tdecl %0\n\tjns 1b" : "=a" (dummy) : "0" (loops)); } </pre> <p>Note that the asm construct now has an output operand, but it is unused. Normally asm constructs with only unused output operands may be removed by gcc, unless marked <tt>volatile</tt> as above.</p> <hr> <h2><a name="linuxkernel">Building Linux kernels</a></h2> <p>The linux kernel violates certain aliasing rules specified in the ANSI/ISO standard. Starting with GCC 2.95, the gcc optimizer by default relies on these rules to produce more efficient code and thus will produce malfunctioning kernels. To work around this problem, the flag <CODE>-fno-strict-aliasing</CODE> must be added to the <CODE>CFLAGS</CODE> variable in the main kernel Makefile.</p> <p>If you try to build a 2.0.x kernel for Intel machines with any compiler other than GCC 2.7.2, then you are on your own. The 2.0.x kernels are to be built only with gcc 2.7.2. They use certain <code>asm</code> constructs which are incorrect, but (by accident) happen to work with gcc 2.7.2. If you insist on building 2.0.x kernels with egcs, you may be interested in this <a href="http://www.suse.de/~florian/kernel+egcs.html">patch</a> which fixes some of the asm problems. You will also want to change asm constructs to <a href="#asmclobber">avoid clobbering their input operands</a>.</p> <p>If you installed a recent binutils/gas snapshot on your GNU/Linux system, you may not be able to build the kernel because objdump does not understand the "-k" switch. The solution for this problem is to remove /usr/bin/encaps. (This is an obsolete program that was part of older binutils distributions; the Linux kernel's Makefile looks for this program to decide if you have an old or a new binutils. Problems occur if you installed a new binutils but haven't removed encaps, because the Makefile thinks you have the old one.)</p> <p>Finally, you may get errors with the X driver of the form </p> <pre> _X11TransSocketUNIXConnect: Can't connect: errno = 111 </pre> <p>This is a kernel bug. The function sys_iopl in arch/i386/kernel/ioport.c does an illegal hack which used to work but is now broken since GCC optimizes more aggressively . The newer 2.1.x kernels already have a fix which should also work in 2.0.32.</p> <hr> <h2><a name="X11R6">How do I compile X11 headers with g++</a></h2> <p>When compiling X11 headers with a GCC 2.95 or newer, g++ will complain that types are missing. These headers assume that omitting the type means 'int'; this assumption is wrong for C++.</p> <p>g++ accepts such (illegal) constructs with the option -fpermissive; it will assume that missing type is 'int' (as defined by the C89 standard).</p> <p>Since the upcoming C99 standard also obsoletes the implicit type assumptions, the X11 headers have to get fixed eventually.</p> <hr> <h2><a name="cross">How to build a cross compiler</a></h2> <p> Building cross compilers is a rather complex undertaking because they usually need additional software (cross assembler, cross linker, target libraries, target include files, etc).</p> <p>We recommend reading the <a href="http://www.objsw.com/CrossGCC/"> crossgcc FAQ</a> for information about building cross compilers.</p> <p>If you have all the pieces available, then `make cross' should build a cross compiler. `make LANGUAGES="c c++" install' will install the cross compiler.</p> <p>Note that if you're trying to build a cross compiler in a tree which includes binutils-2.8 in addition to GCC, then you're going to need to make a couple minor tweaks so that the cross assembler, linker and nm utilities will be found.</p> <p>binutils-2.8 builds those files as gas.new, ld.new and nm.new; GCC looks for them using gas-new, ld-new and nm-new, so you may have to arrange for any symlinks which point to <file>.new to be changed to <file>-new.</p> <hr> <a name="bugs"></a> <h1>Bugs and Non-Bugs</h1> <p>Unfortunately, improvements in tools that are widely used are sooner or later bound to break <em>something</em>. Sometimes, the code that breaks was wrong, and then that code should be fixed, even if it works for earlier versions of gcc or other compilers. The following problems with some releases of widely used packages have been identified:</p> <p>There is a separate <a href="bugs.html">list of well-known bugs</a> describing known deficiencies. Naturally we'd like that list to be of zero length.</p> <p>To report a bug, see <a href="#bugreport">How to report bugs</a>.</p> <hr> <h2><a name="fdzero">FD_ZERO macro</a></h2> <p>The FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect. It uses <a href="#asmclobber">invalid asm clobbers</a>. The following rewrite by Ulrich Drepper <drepper@cygnus.com> should fix this for glibc 2.0:</p> <pre> # define __FD_ZERO(fdsetp) \ do { \ int __d0, __d1; \ __asm__ __volatile__ ("cld; rep; stosl" \ : "=m" (((__fd_mask *) \ (fdsetp))[__FDELT (__FD_SETSIZE)]), \ "=&c" (__d0), "=&D" (__d1) \ : "a" (0), "1" (sizeof (__fd_set) \ / sizeof (__fd_mask)), \ "2" ((__fd_mask *) (fdsetp)) \ : "memory"); \ } while (0) </pre> <hr> <h2><a name="octave">Octave 2.0.13 does not compile</a></h2> <p>Apparently Octave 2.0.13 uses some C++ features which have been obsoleted and thus fails to build with EGCS 1.1 and later. This <a href="http://www.che.wisc.edu/octave/mailing-lists/bug-octave/1998/270">patch to Octave</a> should fix this.</p> <p>Octave 2.0.13.96, a test release, has been compiled without patches by egcs 1.1.2. It is available at <a href="ftp://ftp.che.wisc.edu/pub/octave/test-releases/"> ftp://ftp.che.wisc.edu/pub/octave/test-releases/</a>.</p> <hr> <h2><a name="stdin">Why can't I initialize a static variable with <tt>stdin</tt>?</a></h2> <p>This has nothing to do with gcc, but people ask us about it a lot. Code like this:</p> <pre> #include <stdio.h> FILE *yyin = stdin; </pre> <p>will not compile with GNU libc (Linux libc6), because <tt>stdin</tt> is not a constant. This was done deliberately, in order for there to be no limit on the number of open FILE objects. It is surprising for people used to traditional Unix C libraries, but it is permitted by the C standard.</p> <p>This construct commonly occurs in code generated by old versions of lex or yacc. We suggest you try regenerating the parser with a current version of flex or bison, respectively. In your own code, the appropriate fix is to move the initialization to the beginning of main.</p> <p>There is a common misconception that the GCC developers are responsible for GNU libc. These are in fact two entirely separate projects. The appropriate place to ask questions relating to GNU libc is <a href="mailto:libc-alpha@sourceware.cygnus.com">libc-alpha@sourceware.cygnus.com</a>. </p> <hr> <h2><a name="macarg">Why can't I use #if here?</a></h2> <p>Let me guess... you wrote code that looks something like this:</p> <pre> memcpy(dest, src, #ifdef PLATFORM1 12 #else 24 #endif ); </pre> <p>and you got a whole pile of error messages:</p> <pre> test.c:11: warning: preprocessing directive not recognized within macro arg test.c:11: warning: preprocessing directive not recognized within macro arg test.c:11: warning: preprocessing directive not recognized within macro arg test.c: In function `foo': test.c:6: undefined or invalid # directive test.c:8: undefined or invalid # directive test.c:9: parse error before `24' test.c:10: undefined or invalid # directive test.c:11: parse error before `#' </pre> <p>The problem, simply put, is that GCC's preprocessor does not allow you to put #ifdef (or any other directive) inside the arguments of a macro. Your C library's <tt>string.h</tt> happens to define <tt>memcpy</tt> as a macro - this is perfectly legitimate. The code therefore will not compile.</p> <p>We have two good reasons for not allowing directives inside macro arguments. First, it is not portable. It is "undefined behavior" according to the C standard; that means different compilers will do different things with it. Some will give you errors. Some will dump core. Some will silently mangle your code - you could get the equivalent of</p> <pre> memcpy(dest, src, 1224); </pre> <p>from the above example. A very few might do what you expected it to. We therefore feel it is most useful for GCC to reject this construct immediately so that it is found and fixed.</p> <p>Second, it is extraordinarily difficult to implement the preprocessor such that it does what you would expect for every possible directive found inside a macro argument. The best example is perhaps</p> <pre> #define foo(arg) ... arg ... foo(blah #undef foo blah) </pre> <p>which is <emph>impossible</emph> to implement in portable C without leaking memory. Allowing only a subset of directives would be confusing.</p> <p>It is always possible to rewrite code which uses conditionals inside macros so that it doesn't. You could write the above example</p> <pre> #ifdef PLATFORM1 memcpy(dest, src, 12); #else memcpy(dest, src, 24); #endif </pre> <p>This is a bit more typing, but I personally think it's better style in addition to being more portable. <hr> <a name="misc"></a> <h1>Miscellaneous</h1> <h2><a name="memexhausted">Virtual memory exhausted error</a></h2> <p> This error means your system ran out of memory; this can happen for large files, particularly when optimizing. If you're getting this error you should consider trying to simplify your files or reducing the optimization level.</p> <p>Note that using -pedantic or -Wreturn-type can cause an explosion in the amount of memory needed for template-heavy C++ code, such as code that uses STL. Also note that -Wall includes -Wreturn-type, so if you use -Wall you will need to specify -Wno-return-type to turn it off.</p> <hr> <h2><a name="snapshot">Snapshots, how, when, why</a></h2> <p> We make snapshots of the GCC sources about once a week; there is no predetermined schedule. These snapshots are intended to give everyone access to work in progress. Any given snapshot may generate incorrect code or even fail to build.</p> <p>If you plan on downloading and using snapshots, we highly recommend you subscribe to the GCC mailing lists. See <a href="index.html#mailinglists"> mailing lists</a> on the main GCC page for instructions on how to subscribe.</p> <p>When using the diff files to update from older snapshots to newer snapshots, make sure to use "-E" and "-p" arguments to patch so that empty files are deleted and full pathnames are provided to patch. If your version of patch does not support "-E", you'll need to get a newer version. Also note that you may need autoconf, autoheader and various other programs if you use diff files to update from one snapshot to the next.</p> <hr> <h2><a name="friend">Friend Templates</a></h2> <p>In order to make a specialization of a template function a friend of a (possibly template) class, you must explicitly state that the friend function is a template, by appending angle brackets to its name, and this template function must have been declared already. Here's an example:</p> <pre> template <typename T> class foo { friend void bar(foo<T>); } </pre> <p>The above declaration declares a non-template function named <TT>bar</TT>, so it must be explicitly defined for <B>each</B> specialization of <TT>foo</TT>. A template definition of <TT>bar</TT> won't do, because it is unrelated with the non-template declaration above. So you'd have to end up writing:</p> <pre> void bar(foo<int>) { /* ... */ } void bar(foo<void>) { /* ... */ } </pre> <p>If you meant <TT>bar</TT> to be a template function, you should have forward-declared it as follows. Note that, since the template function declaration refers to the template class, the template class must be forward-declared too:</p> <pre> template <typename T> class foo; template <typename T> void bar(foo<T>); template <typename T> class foo { friend void bar<>(foo<T>); }; template <typename T> void bar(foo<T>) { /* ... */ } </pre> <p>In this case, the template argument list could be left empty, because it can be implicitly deduced from the function arguments, but the angle brackets must be present, otherwise the declaration will be taken as a non-template function. Furthermore, in some cases, you may have to explicitly specify the template arguments, to remove ambiguity.</p> <p>An error in the last public comment draft of the ANSI/ISO C++ Standard and the fact that previous releases of gcc would accept such friend declarations as template declarations has led people to believe that the forward declaration was not necessary, but, according to the final version of the Standard, it is.</p> <hr> <h2><a name="libg++">Where to find libg++</a></h2> <p>Many folks have been asking where to find libg++ for GCC. First we should point out that few programs actually need libg++; most only need libstdc++/libio which are included in the GCC distribution.</p> <p>If you do need libg++ you can get a libg++ release that works with GCC from <a href="ftp://egcs.cygnus.com/pub/egcs/infrastructure/">ftp://egcs.cygnus.com/pub/egcs/infrastructure/</a>. Note that the 2.8.2 snapshot pre-dates the 2.8.1.2 release.</p> <hr> <h2><a name="generated_files">autoconf, bison, xgettext, automake, etc</a></h2> <p>If you're using diffs up dated from one snapshot to the next, or if you're using the CVS repository, you may need several additional programs to build GCC.</p> <p>These include, but are not necessarily limited to autoconf, automake, bison, and xgettext.</p> <p>This is necessary because neither diff nor cvs keep timestamps correct. This causes problems for generated files as "make" may think those generated files are out of date and try to regenerate them.</p> <p>An easy way to work around this problem is to use the <CODE>gcc_update </CODE> script in the contrib subdirectory of GCC, which handles this transparently without requiring installation of any additional tools. (Note: Up to and including GCC 2.95 this script was called <CODE>egcs_update </CODE>.)</p> <p>When building from diffs or CVS or if you modified some sources, you may also need to obtain development versions of some GNU tools, as the production versions do not necessarily handle all features needed to rebuild GCC.</p> <p>Autoconf is available from <a href="http://sourceware.cygnus.com/autoconf/"> http://sourceware.cygnus.com/autoconf/</a>; have a look at <a href="ftp://egcs.cygnus.com/pub/egcs/infrastructure/"> ftp://egcs.cygnus.com/pub/egcs/infrastructure/</a> for the other packages. </p> <hr> <h2><a name="conflicts">Conflicts when using cvs update</a></h2> <p>It is not uncommon to get CVS conflict messages for some generated files when updating your local sources from the CVS repository. Typically such conflicts occur with bison or autoconf generated files.</p> <p>As long as you haven't been making modifications to the generated files or the generator files, it is safe to delete the offending file, then run cvs update again to get a new copy.</p> <hr> <h2><a name="gdb">Problems debugging GCC code</a></h2> <p>On some systems GCC will produce dwarf debug records by default; however the gdb-4.16 release may not be able to read such debug records.</p> <p>You can either use the argument "-gstabs" instead of "-g" or pick up a copy of gdb-4.17 to work around the problem. <hr> <h2><a name="gnat">Using GCC with GNAT/Ada </a></h2> <p>The GNU Ada front-end is not currently supported by GCC; however, it is possible to build the GNAT compiler with a little work.</p> <p>First, retrieve the gnat-3.10p sources. The sources for the Ada front end and runtime all live in the "ada" subdirectory. Move that subdirectory to egcs/gcc/ada.</p> <p>Second, apply the patch found in egcs/gcc/README.gnat.</p> <p>Finally, rebuild per the GNAT build instructions.</p> <hr> <h2><a name="gpc">Using GCC with GNU Pascal</a></h2> <p>The <a href="http://home.pages.de/~GNU-Pascal/">GNU Pascal</a> front-end does work with EGCS 1.1 It does not work with EGCS 1.0.x and the main branch of the CVS repository. A tarball can be found at <A HREF="ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/"> ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/</A>.</p> <hr> <h2><a name="cvssnapshots">Using CVS to download snapshots</a></h2> <p>It is possible to checkout specific snapshots with CVS or to check out the latest snapshot.</p> <p>We use CVS tags to identify each snapshot we make. Snapshot tags have the form "egcs_ss_YYYYMMDD". In addition, the latest official snapshot always has the tag "gcc_latest_snapshot".</p> <hr> <h2><a name="picflag-needed">Why can't I build a shared library?</a></h2> <p>When building a shared library you may get an error message from the linker like `assert pure-text failed:' or `DP relative code in file'.</p> <p>This kind of error occurs when you've failed to provide proper flags to gcc when linking the shared library. </p> <p>You can get this error even if all the .o files for the shared library were compiled with the proper PIC option. When building a shared library, gcc will compile additional code to be included in the library. That additional code must also be compiled with the proper PIC option.</p> <p>Adding the proper PIC option (<tt>-fpic</tt> or <tt>-fPIC</tt>) to the link line which creates the shared library will fix this problem on targets that support PIC in this manner. For example:</p> <pre> gcc -c -fPIC myfile.c gcc -shared -o libmyfile.so -fPIC myfile.o </pre> <hr> <h2><a name="squangle">How to work around too long C++ symbol names? (<tt>-fsquangle</tt>)</a></h2> <p>If the standard assembler of your platform can't cope with the large symbol names that the default g++ name mangling mechanism produces, your best bet is to use GNU as, from the GNU binutils package.</p> <p>Unfortunately, GNU as does not support all platforms supported by egcs, so you may have to use an experimental work-around: the <tt>-fsquangle</tt> option, that enables compression of symbol names.</p> <p>Note that this option is still under development, and subject to change. Since it modifies the name mangling mechanism, you'll need to build libstdc++ and any other C++ libraries with this option enabled. Furthermore, if this option changes its behavior in the future, you'll have to rebuild them all again. :-(</p> <p>This option can be enabled by default by initializing `flag_do_squangling' with `1' in `gcc/cp/decl2.c' (it is not initialized by default), then rebuilding egcs and any C++ libraries.</p> <hr> <h2><a name="gperf">When building from CVS sources, I see 'gperf: invalid option -- F', even with the most current version of gperf. </a></h2> <p>The current version of gperf (v2.7) does not support the -F flag which is used when building egcs from CVS sources. You will need to obtain a patch for gperf and rebuild the program; this patch is available at <a href="ftp://egcs.cygnus.com/pub/egcs/infrastructure"> ftp://egcs.cygnus.com/pub/egcs/infrastructure/</a></p> <p>Patches for other tools, particularly autoconf, may also be necessary if you're building from CVS sources. Please see the <a href="#generated_files">FAQ entry</a> regarding these tools to determine if anything else is needed.</p> <p>These patched utilities should <strong>only</strong> be required if you are building from CVS sources. For example, gperf is used to generate C code for a perfect hash function given an input file. Distributions of egcs already contain the generated C code, while the CVS sources will provide only the gperf input file. So gperf should only be necessary if you are building anything obtained from CVS.</p> <hr> <h2><a name="vtables">When building C++, the linker says my constructors, destructors or virtual tables are undefined, but I defined them</a></h2> <p>The ISO C++ Standard specifies that all virtual methods of a class that are not pure-virtual must be defined, but does not require any diagnostic for violations of this rule [class.virtual]/8. Based on this assumption, egcs will only emit the implicitly defined constructors, the assignment operator, the destructor and the virtual table of a class in the translation unit that defines its first such non-inline method.</p> <p>Therefore, if you fail to define this particular method, the linker may complain about the lack of definitions for apparently unrelated symbols. Unfortunately, in order to improve this error message, it might be necessary to change the linker, and this can't always be done.</p> <p>The solution is to ensure that all virtual methods that are not pure are defined. Note that a destructor must be defined even if it is declared pure-virtual [class.dtor]/7.</p> <hr> <h2><a name="libstdc++">What is libstdc++-v3 and how can I use it with g++?</a></h2> <p>From the <a href="http://sourceware.cygnus.com/libstdc++/faq/">libstdc++-FAQ</a>: "The EGCS Standard C++ Library v3, or libstdc++-2.90.x, is an ongoing project to implement the ISO 14882 Standard C++ library as described in chapters 17 through 27 and annex D."</p> <p>At the moment the libstdc++-v3 is no "drop in replacement" for GCC's libstdc++. The best way to use it is as follows:</p> <ol> <li>Build and install GCC</li> <li>Build and install libstdc++-v3</li> <li>Use compiler flags to use the new libstdc++</li> </ol> <p>Please note that the libstdc++-v3 is not yet complete and should only be used by experienced programmers.</p> <p>For more information please refer to the <a href="http://sourceware.cygnus.com/libstdc++/">libstdc++-v3 homepage</a></p> <hr> <p><a href="index.html">Return to the GCC home page</a></p> <p><i>Last modified: October 19, 1999</i></p> </body> </html>