GCC Frequently Asked Questions The latest version of this document is always available at [1]http://www.gnu.org/software/gcc/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 the relationship between GCC and Cygnus / Red Hat? 3. [10]What is an open development model? 4. [11]How do I report a bug? 5. [12]How do I get a bug fixed or a feature added? 6. [13]Does GCC work on my platform? 2. [14]Installation 1. [15]How to install multiple versions of GCC 2. [16]Dynamic linker is unable to find GCC libraries 3. [17]libstdc++/libio tests fail badly with --enable-shared 4. [18]GCC can not find GNU as/GNU ld 5. [19]cpp: Usage:... Error 6. [20]Optimizing the compiler itself 3. [21]Testsuite problems 1. [22]Unable to run the testsuite 2. [23]How do I pass flags like -fnew-abi to the testsuite? 3. [24]How can I run the test suite with multiple options? 4. [25]Older versions of GCC 1. [26]Is there a stringstream / sstream for GCC 2.95.2? 5. [27]Miscellaneous 1. [28]Virtual memory exhausted 2. [29]Friend Templates 3. [30]dynamic_cast, throw, typeid don't work with shared libraries 4. [31]Why do I need autoconf, bison, xgettext, automake, etc? 5. [32]Why can't I build a shared library? 6. [33]How to work around too long C++ symbol names? (-fsquangle) 7. [34]When building C++, the linker says my constructors, destructors or virtual tables are undefined, but I defined them 8. [35]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 limitiations 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 [36]GCC Steering Committee. _________________________________________________________________ What is the relationship between GCC and Cygnus / Red Hat? It is a common mis-conception that Red Hat controls GCC either directly or indirectly. While Red Hat does donate hardware, network connections, code and developer time to GCC development, Red Hat does not control GCC. Overall control of GCC is in the hands of the [37]GCC Steering Committee 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. To summarize, Red Hat contributes to the GCC project, but does not exert a controlling influence over GCC. _________________________________________________________________ What is an open development model? We are using a bazaar style [38][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 ``[39]The Cathedral and the Bazaar''. The paper is a useful starting point for discussions. _________________________________________________________________ How do I report a bug? There are complete instructions [40]here. _________________________________________________________________ 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 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. * 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. * [41]Report the problem to the GCC GNATS 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. This alternative will work best if you follow the directions on [42]submitting bugreports. * 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. _________________________________________________________________ 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 [43]latest version is always available at the GCC web site. Reports of [44]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, [45]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 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 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. To ensure that GCC finds the GNU assembler (the GNU loader), which are required by [46]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 _________________________________________________________________ Testsuite problems Unable to run the testsuite 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 from [47]http://www.gnu.org/software/dejagnu/dejagnu.html. _________________________________________________________________ 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" 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,}" 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. _________________________________________________________________ Older versions of GCC and EGCS Is there a stringstream / sstream for GCC 2.95.2? Yes, it's at: [48]http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream. _________________________________________________________________ Miscellaneous Virtual memory exhausted error 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. 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. _________________________________________________________________ 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 class foo { friend void bar(foo); } 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) { /* ... */ } void bar(foo) { /* ... */ } 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 class foo; template void bar(foo); template class foo { friend void bar<>(foo); }; template void bar(foo) { /* ... */ } 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::typeinfo_t 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 need taking. * 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 [49]ABI specification. Note the std::typeinfo_t 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 CVS 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. (Note: Up to and including GCC 2.95 this script was called egcs_update .) 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. In general, the current versions of these tools from [50]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 [51]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 _________________________________________________________________ How to work around too long C++ symbol names (-fsquangle) This question does not apply to GCC 3.0 or later versions, which have a new C++ ABI with much shorter mangled names. 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. Unfortunately, GNU as does not support all platforms supported by GCC, so you may have to use an experimental work-around: the -fsquangle option, that enables compression of symbol names. 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. :-( 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. _________________________________________________________________ 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. _________________________________________________________________ Will GCC someday include an incremental linker? Incremental linking is part of the linker, not the compiler. As such, GCC doesn't have anything to do with incremental linking. Depending on what platform you use, it may be possible to tell GCC to use the platform's native linker (e.g., Solaris' ild(1)). References 1. http://www.gnu.org/software/gcc/faq.html 2. http://www.eskimo.com/~scs/C-faq/top.html 3. http://www.research.att.com/~austern/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#gcc 9. http://gcc.gnu.org/faq.html#cygnus 10. http://gcc.gnu.org/faq.html#open-development 11. http://gcc.gnu.org/faq.html#bugreport 12. http://gcc.gnu.org/faq.html#support 13. http://gcc.gnu.org/faq.html#platforms 14. http://gcc.gnu.org/faq.html#installation 15. http://gcc.gnu.org/faq.html#multiple 16. http://gcc.gnu.org/faq.html#rpath 17. http://gcc.gnu.org/faq.html#rpath 18. http://gcc.gnu.org/faq.html#gas 19. http://gcc.gnu.org/faq.html#environ 20. http://gcc.gnu.org/faq.html#optimizing 21. http://gcc.gnu.org/faq.html#testsuite 22. http://gcc.gnu.org/faq.html#dejagnu 23. http://gcc.gnu.org/faq.html#testoptions 24. http://gcc.gnu.org/faq.html#multipletests 25. http://gcc.gnu.org/faq.html#old 26. http://gcc.gnu.org/faq.html#2.95sstream 27. http://gcc.gnu.org/faq.html#misc 28. http://gcc.gnu.org/faq.html#memexhausted 29. http://gcc.gnu.org/faq.html#friend 30. http://gcc.gnu.org/faq.html#dso 31. http://gcc.gnu.org/faq.html#generated_files 32. http://gcc.gnu.org/faq.html#picflag-needed 33. http://gcc.gnu.org/faq.html#squangle 34. http://gcc.gnu.org/faq.html#vtables 35. http://gcc.gnu.org/faq.html#incremental 36. http://gcc.gnu.org/steering.html 37. http://gcc.gnu.org/steering.html 38. http://gcc.gnu.org/faq.html#cathedral-vs-bazaar 39. http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ 40. http://gcc.gnu.org/bugs.html 41. http://gcc.gnu.org/bugs.html 42. http://gcc.gnu.org/bugs.html 43. http://gcc.gnu.org/install/specific.html 44. http://gcc.gnu.org/buildstat.html 45. http://gcc.gnu.org/faq.html#gas 46. http://gcc.gnu.org/install/specific.html 47. http://www.gnu.org/software/dejagnu/dejagnu.html 48. http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream 49. http://www.codesourcery.com/cxx-abi/ 50. ftp://ftp.gnu.org/gnu/ 51. ftp://gcc.gnu.org/pub/gcc/infrastructure/