This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
PATCH: Zap most of faq.html
- To: gcc-patches at gcc dot gnu dot org
- Subject: PATCH: Zap most of faq.html
- From: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Date: Mon, 13 Mar 2000 01:04:15 +0100 (CET)
This removed most of the old FAQ and links to the F-O-M instead.
Gerald
Index: faq.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v
retrieving revision 1.158
diff -c -3 -p -r1.158 faq.html
*** faq.html 2000/02/15 23:54:02 1.158
--- faq.html 2000/03/13 00:02:21
***************
*** 8,15 ****
<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
--- 8,14 ----
<h1 align="center">GCC Frequently Asked Questions</h1>
! <p>This <a href="http://gcc.gnu.org/cgi-bin/fom">FAQ has moved.</p>
<p>This FAQ tries to answer specific questions concerning GCC. For
general information regarding C, C++, resp. Fortran please check the
*************** comp.std.c++ FAQ</a>, and the <a
*** 21,1118 ****
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="#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="#sparcv9">How to build a compiler for sparcv9/sparc64/UltraSPARC</a></li>
- <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>
- <li><a href="#rounding">Problems with floating point computations</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="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 its 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 alternative 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://gcc.gnu.org/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="sparcv9">How to build a compiler for sparcv9/sparc64/UltraSPARC?</a></h2>
-
- <p>GCC up to version 2.95.x does not fully support the SPARC version 9
- architecture. Even though the port for this architecture is in use by
- a number of projects already, the compiler has a several deficiencies.
- In particular, it generates assembler code not accepted by some
- Solaris 7 assemblers, and it is known to generate bad code for some
- floating-point operations. You don't need to report that there are
- bugs; we know.</p>
-
- <p>Therefore, it is recommended to use GCC in 32-bit mode only on
- UltraSPARC machines, even on Solaris 7 or newer. If you absolutely need
- to experiment with a compiler for that architecture, you may want to
- try our development snapshots, which contain a number of
- improvements. Hopefully, the next major release of GCC will support
- this architecture.</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.
- Development snapshots and releases are available at <a
- href="ftp://ftp.valinux.com/pub/support/hjl/binutils/">
- ftp://ftp.valinux.com/pub/support/hjl/binutils/</a> and <a
- href="http://sourceware.cygnus.com/binutils/">
- http://sourceware.cygnus.com/binutils/</a>. The old 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 later versions of GCC (or 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.
-
- <h2><a name="rounding">Problems with floating point computations</a></h2>
-
- <p>In a number of cases, gcc appears to perform floating point
- computations incorrectly. For example, the program</p>
- <pre>
- #include <iostream.h>
-
- main() {
-
- double min = 0.0;
- double max = 0.5;
- double width = 0.01;
- cout << (int)(((max - min) / width) - 1) << endl;
-
- }
- </pre>
- <p>might print 50 on some systems and optimization levels, and 51 on
- others.</p>
-
- <p>The is the result of <em>rounding</em>: The computer cannot
- represent all real numbers exactly, so it has to use
- approximations. When computing with approximation, the computer needs
- to round to the nearest representable number.</p>
-
- <p>This is not a bug in the compiler, but an inherent limitation of
- the float and double types. Please study
- <a href="http://www.validgh.com/goldberg/paper.ps">this paper</a>
- for more information.</p>
-
- <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://gcc.gnu.org/pub/egcs/infrastructure/">ftp://gcc.gnu.org/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://gcc.gnu.org/pub/egcs/infrastructure/">
- ftp://gcc.gnu.org/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 "gcc_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
- GCC, 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 GCC 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 GCC from CVS sources. You will need to
- obtain a patch for gperf and rebuild the program; this patch is available
- at <a href="ftp://gcc.gnu.org/pub/egcs/infrastructure">
- ftp://gcc.gnu.org/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 GCC 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, GCC 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>
<h2><a name="bugreport">How to report bugs</a></h2>
<p>Our <a href="bugs.html">bug reporting instructions have moved</a>!</p>
--- 20,25 ----