source: trunk/gcc/FAQ@ 2494

                        GCC Frequently Asked Questions

   The latest version of this document is always available at
   [1]http://gcc.gnu.org/faq.html.

   This FAQ tries to answer specific questions concerning GCC. For
   general information regarding C, C++, resp. Fortran please check the
   [2]comp.lang.c FAQ, [3]comp.std.c++ FAQ, and the [4]Fortran
   Information page.

   Other GCC-related FAQs: [5]libstdc++-v3, and [6]GCJ.
     _________________________________________________________________

                                   Questions

    1. [7]General information
         1. [8]What is the relationship between GCC and EGCS?
         2. [9]What is an open development model?
         3. [10]How do I get a bug fixed or a feature added?
         4. [11]Does GCC work on my platform?
    2. [12]Installation
         1. [13]How to install multiple versions of GCC
         2. [14]Dynamic linker is unable to find GCC libraries
         3. [15]libstdc++/libio tests fail badly with --enable-shared
         4. [16]GCC can not find GNU as/GNU ld
         5. [17]cpp: Usage:... Error
         6. [18]Optimizing the compiler itself
         7. [19]Why does libiconv get linked into jc1 on Solaris?
    3. [20]Testsuite problems
         1. [21]How do I pass flags like -fnew-abi to the testsuite?
         2. [22]How can I run the test suite with multiple options?
    4. [23]Older versions of GCC
         1. [24]Is there a stringstream / sstream for GCC 2.95.2?
    5. [25]Miscellaneous
         1. [26]Friend Templates
         2. [27]dynamic_cast, throw, typeid don't work with shared
            libraries
         3. [28]Why do I need autoconf, bison, xgettext, automake, etc?
         4. [29]Why can't I build a shared library?
         5. [30]When building C++, the linker says my constructors,
            destructors or virtual tables are undefined, but I defined
            them
         6. [31]Will GCC someday include an incremental linker?
     _________________________________________________________________

                              General information

What is the relationship between GCC and EGCS?

   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 limitations and gcc version 2 was the
   result.

   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.

   In April 1999 the Free Software Foundation officially halted
   development on the gcc2 compiler and appointed the EGCS project as the
   official GCC maintainers. The net result was a single project which
   carries forward GCC development under the ultimate control of the
   [32]GCC Steering Committee.
     _________________________________________________________________

What is an open development model?

   We are using a bazaar style [33][1] approach to GCC development: we
   make snapshots publicly available to anyone who wants to try them; we
   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.

   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.

   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.

   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.

   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.

   With GCC, we are adding new features and optimizations at a rate that
   has not been done since the creation of gcc2; these additions
   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.

     [1] 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 cathedral development model versus a bazaar
     development model. The paper is written by Eric S. Raymond, it is
     called ``The Cathedral and the Bazaar''. The paper is a useful
     starting point for discussions.
     _________________________________________________________________

How do I get a bug fixed or a feature added?

   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 decreasing 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.
     * 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.
     * [34]Report the problem to the GCC bug tracking system 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 this method
       that you would see from a commercial support organization since
       the people who read GCC bug reports, if they choose to help you,
       will be volunteering their time.
     * 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.
     _________________________________________________________________

Does GCC work on my platform?

   The host/target specific installation notes for GCC include
   information about known problems with installing or using GCC on
   particular platforms. These are included in the sources for a release
   in INSTALL/specific.html, and the [35]latest version is always
   available at the GCC web site. Reports of [36]successful builds for
   several versions of GCC are also available at the web site.
     _________________________________________________________________

                                 Installation

How to install multiple versions of GCC

   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.

   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.

   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.

   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.

   If you use --prefix, GCC may have difficulty locating a GNU assembler
   or linker on your system, [37]GCC can not find GNU as/GNU ld explains
   how to deal with this.

   Another option that may be easier is to use the --program-prefix= or
   --program-suffix= options to configure. So if you're installing GCC
   2.95.2 and don't want to disturb the current version of GCC in
   /usr/local/bin/, you could do

     configure --program-suffix=-2.95.2 <other configure options>

   This should result in GCC being installed as /usr/local/bin/gcc-2.95.2
   instead of /usr/local/bin/gcc.
     _________________________________________________________________

Dynamic linker is unable to find GCC libraries

   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.

   GCC does not specify a runpath so that the dynamic linker can find
   dynamic libraries at runtime.

   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.

   The problem is not programs that do require the directories; those