                         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]How do I get a bug fixed or a feature added?
         2. [9]Does GCC work on my platform?
    2. [10]Installation
         1. [11]How to install multiple versions of GCC
         2. [12]Dynamic linker is unable to find GCC libraries
         3. [13]libstdc++/libio tests fail badly with --enable-shared
         4. [14]GCC can not find GNU as/GNU ld
         5. [15]cpp: Usage:... Error
         6. [16]Optimizing the compiler itself
         7. [17]Why does libiconv get linked into jc1 on Solaris?
    3. [18]Testsuite problems
         1. [19]How do I pass flags like -fnew-abi to the testsuite?
         2. [20]How can I run the test suite with multiple options?
    4. [21]Miscellaneous
         1. [22]Friend Templates
         2. [23]dynamic_cast, throw, typeid don't work with shared
            libraries
         3. [24]Why do I need autoconf, bison, xgettext, automake, etc?
         4. [25]Why can't I build a shared library?
         5. [26]When building C++, the linker says my constructors,
            destructors or virtual tables are undefined, but I defined
            them
     __________________________________________________________________

                              General information

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.
     * [27]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 [28]latest version is always available
   at the GCC web site. Reports of [29]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, [30]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
   programs are going to hang no matter what you do. The problem is
   programs that do not require the directories.

   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.

   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 gcc
   -print-prog-name=cc1 to find it). You may add linker flags such as -R
   or -rpath, depending on platform and linker, to the *link or *lib
   specs.

   Another alternative is to install a wrapper script around gcc, g++ or
   ld that adds the appropriate directory to the environment variable
   LD_RUN_PATH or equivalent (again, it's platform-dependent).

   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 .ml file within
   libstdc++/config (and also libg++/config, if you are building libg++),
   so that $(libdir)/ appears just before the library name in -soname or
   -h options.
     __________________________________________________________________

GCC can not find GNU as/GNU ld

   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 assembler 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.

   To ensure that GCC finds the GNU assembler (the GNU loader), which are
   required by [31]some configurations, 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.

   Another alternative is to create links to GNU as and ld in any of the
   directories printed by the command `gcc -print-search-dirs | grep
   '^programs:''. The link to `ld' should be named `real-ld' if `ld'
   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
   gcc directory and in all the gcc/stage* subdirectories.

   GCC 2.95 allows you to specify the full pathname of the assembler and
   the linker to use. The configure flags are `--with-as=/path/to/as' and
   `--with-ld=/path/to/ld'. GCC will try to use these pathnames before
   looking for `as' or `(real-)ld' in the standard search dirs. If, at
   configure-time, the specified programs are found to be GNU utilities,
   `--with-gnu-as' and `--with-gnu-ld' 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 -B/path/ if the specified filenames exist.
     __________________________________________________________________

cpp: Usage:... Error

   If you get an error like this when building GCC (particularly when
   building __mulsi3), then you likely have a problem with your
   environment variables.
  cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp
  [switches] input output

   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.

   Also note '::' in these paths will also cause similar problems.
     __________________________________________________________________

Optimizing the compiler itself

   If you want to test a particular optimization option, it's useful to
   try bootstrapping the compiler with that option turned on. For example,
   to test the -fssa option, you could bootstrap like this:
make BOOT_CFLAGS="-O2 -fssa" bootstrap
     __________________________________________________________________

Why does libiconv get linked into jc1 on Solaris?

   The Java front end requires iconv. If the compiler used to bootstrap
   GCC finds libiconv (because the GNU version of libiconv has been
   installed in the same prefix as the bootstrap compiler), but the newly
   built GCC does not find the library (because it will be installed with
   a different prefix), then a link-time error will occur when building
   jc1. This problem does not show up so often on platforms that have
   libiconv in a default location (like /usr/lib) because then both
   compilers can find a library named libiconv, even though it is a
   different library.

   Using --disable-nls at configure-time does not prevent this problem
   because jc1 uses iconv even in that case. Solutions include temporarily
   removing the GNU libiconv, copying it to a default location such as
   /usr/lib/, and using --enable-languages at configure-time to disable
   Java.
     __________________________________________________________________

                               Testsuite problems

How do I pass flags like -fnew-abi to the testsuite?

   If you invoke runtest directly, you can use the --tool_opts option,
   e.g:
  runtest --tool_opts "-fnew-abi -fno-honor-std" <other options>

   Or, if you use make check you can use the make variable RUNTESTFLAGS,
   e.g:
  make RUNTESTFLAGS="--tool_opts '-fnew-abi -fno-honor-std'" check-g++
     __________________________________________________________________

How can I run the test suite with multiple options?

   If you invoke runtest directly, you can use the --target_board option,
   e.g:
  runtest --target_board "unix{-fPIC,-fpic,}" <other options>

   Or, if you use make check you can use the make variable RUNTESTFLAGS,
   e.g:
  make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-gcc

   Either of these examples will run the tests three times. Once with
   -fPIC, once with -fpic, and once with no additional flags.

   This technique is particularly useful on multilibbed targets.
     __________________________________________________________________

                                 Miscellaneous

Friend Templates

   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:
template <typename T> class foo {
  friend void bar(foo<T>);
}

   The above declaration declares a non-template function named bar, so it
   must be explicitly defined for each specialization of foo. A template
   definition of bar won't do, because it is unrelated with the
   non-template declaration above. So you'd have to end up writing:
void bar(foo<int>) { /* ... */ }
void bar(foo<void>) { /* ... */ }

   If you meant bar 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:
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>) { /* ... */ }

   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.

   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.
     __________________________________________________________________

dynamic_cast, throw, typeid don't work with shared libraries

   The new C++ ABI in the GCC 3.0 series uses address comparisons, rather
   than string compares, to determine type equality. This leads to better
   performance. Like other objects that have to be present in the final
   executable, these std::type_info objects have what is called vague
   linkage because they are not tightly bound to any one particular
   translation unit (object file). The compiler has to emit them in any
   translation unit that requires their presence, and then rely on the
   linking and loading process to make sure that only one of them is
   active in the final executable. With static linking all of these
   symbols are resolved at link time, but with dynamic linking, further
   resolution occurs at load time. You have to ensure that objects within
   a shared library are resolved against objects in the executable and
   other shared libraries.
     * For a program which is linked against a shared library, no
       additional precautions are needed.
     * You cannot create a shared library with the "-Bsymbolic" option, as
       that prevents the resolution described above.
     * If you use dlopen to explicitly load code from a shared library,
       you must do several things. First, export global symbols from the
       executable by linking it with the "-E" flag (you will have to
       specify this as "-Wl,-E" if you are invoking the linker in the
       usual manner from the compiler driver, g++). You must also make the
       external symbols in the loaded library available for subsequent
       libraries by providing the RTLD_GLOBAL flag to dlopen. The symbol
       resolution can be immediate or lazy.

   Template instantiations are another, user visible, case of objects with
   vague linkage, which needs similar resolution. If you do not take the
   above precautions, you may discover that a template instantiation with
   the same argument list, but instantiated in multiple translation units,
   has several addresses, depending in which translation unit the address
   is taken. (This is not an exhaustive list of the kind of objects which
   have vague linkage and are expected to be resolved during linking &
   loading.)

   If you are worried about different objects with the same name colliding
   during the linking or loading process, then you should use namespaces
   to disambiguate them. Giving distinct objects with global linkage the
   same name is a violation of the One Definition Rule (ODR)
   [basic.def.odr].

   For more details about the way that GCC implements these and other C++
   features, please read the [32]ABI specification. Note the
   std::type_info objects which must be resolved all begin with "_ZTS".
   Refer to ld's documentation for a description of the "-E" &
   "-Bsymbolic" flags.
     __________________________________________________________________

Why do I need autoconf, bison, xgettext, automake, etc?

   If you're using diffs up dated from one snapshot to the next, or if
   you're using the SVN repository, you may need several additional
   programs to build GCC.

   These include, but are not necessarily limited to autoconf, automake,
   bison, and xgettext.

   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.

   An easy way to work around this problem is to use the gcc_update script
   in the contrib subdirectory of GCC, which handles this transparently
   without requiring installation of any additional tools.

   When building from diffs or SVN 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.

   In general, the current versions of these tools from
   [33]ftp://ftp.gnu.org/gnu/ will work. At present, Autoconf 2.50 is not
   supported, and you will need to use Autoconf 2.13; work is in progress
   to fix this problem. Also look at
   [34]ftp://gcc.gnu.org/pub/gcc/infrastructure/ for any special versions
   of packages.
     __________________________________________________________________

Why can't I build a shared library?

   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'.

   This kind of error occurs when you've failed to provide proper flags to
   gcc when linking the shared library.

   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.

   Adding the proper PIC option (-fpic or -fPIC) to the link line which
   creates the shared library will fix this problem on targets that
   support PIC in this manner. For example:
        gcc -c -fPIC myfile.c
        gcc -shared -o libmyfile.so -fPIC myfile.o
     __________________________________________________________________

When building C++, the linker says my constructors, destructors or virtual
tables are undefined, but I defined them

   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.

   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.

   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.

References

   1. http://gcc.gnu.org/faq.html
   2. http://c-faq.com/
   3. http://www.comeaucomputing.com/csc/faq.html
   4. http://www.fortran.com/fortran/info.html
   5. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html
   6. http://gcc.gnu.org/java/faq.html
   7. http://gcc.gnu.org/faq.html#general
   8. http://gcc.gnu.org/faq.html#support
   9. http://gcc.gnu.org/faq.html#platforms
  10. http://gcc.gnu.org/faq.html#installation
  11. http://gcc.gnu.org/faq.html#multiple
  12. http://gcc.gnu.org/faq.html#rpath
  13. http://gcc.gnu.org/faq.html#rpath
  14. http://gcc.gnu.org/faq.html#gas
  15. http://gcc.gnu.org/faq.html#environ
  16. http://gcc.gnu.org/faq.html#optimizing
  17. http://gcc.gnu.org/faq.html#iconv
  18. http://gcc.gnu.org/faq.html#testsuite
  19. http://gcc.gnu.org/faq.html#testoptions
  20. http://gcc.gnu.org/faq.html#multipletests
  21. http://gcc.gnu.org/faq.html#misc
  22. http://gcc.gnu.org/faq.html#friend
  23. http://gcc.gnu.org/faq.html#dso
  24. http://gcc.gnu.org/faq.html#generated_files
  25. http://gcc.gnu.org/faq.html#picflag-needed
  26. http://gcc.gnu.org/faq.html#vtables
  27. http://gcc.gnu.org/bugs.html
  28. http://gcc.gnu.org/install/specific.html
  29. http://gcc.gnu.org/buildstat.html
  30. http://gcc.gnu.org/faq.html#gas
  31. http://gcc.gnu.org/install/specific.html
  32. http://www.codesourcery.com/cxx-abi/
  33. ftp://ftp.gnu.org/gnu/
  34. ftp://gcc.gnu.org/pub/gcc/infrastructure/
