1: 2: GCC Frequently Asked Questions 3: 4: The latest version of this document is always available at 5: [1]http://gcc.gnu.org/faq.html. 6: 7: This FAQ tries to answer specific questions concerning GCC. For general 8: information regarding C, C++, resp. Fortran please check the [2]comp.lang.c 9: FAQ, [3]comp.std.c++ FAQ, and the [4]Fortran Information page. 10: 11: Other GCC-related FAQs: [5]libstdc++-v3, and [6]GCJ. 12: _________________________________________________________________ 13: 14: Questions 15: 16: 1. [7]General information 17: 1. [8]How do I get a bug fixed or a feature added? 18: 2. [9]Does GCC work on my platform? 19: 2. [10]Installation 20: 1. [11]How to install multiple versions of GCC 21: 2. [12]Dynamic linker is unable to find GCC libraries 22: 3. [13]libstdc++/libio tests fail badly with --enable-shared 23: 4. [14]GCC can not find GNU as/GNU ld 24: 5. [15]cpp: Usage:... Error 25: 6. [16]Optimizing the compiler itself 26: 7. [17]Why does libiconv get linked into jc1 on Solaris? 27: 3. [18]Testsuite problems 28: 1. [19]How do I pass flags like -fnew-abi to the testsuite? 29: 2. [20]How can I run the test suite with multiple options? 30: 4. [21]Miscellaneous 31: 1. [22]Friend Templates 32: 2. [23]dynamic_cast, throw, typeid don't work with shared libraries 33: 3. [24]Why do I need autoconf, bison, xgettext, automake, etc? 34: 4. [25]Why can't I build a shared library? 35: 5. [26]When building C++, the linker says my constructors, destructors 36: or virtual tables are undefined, but I defined them 37: _________________________________________________________________ 38: 39: General information 40: 41: How do I get a bug fixed or a feature added? 42: 43: There are lots of ways to get something fixed. The list below may be 44: incomplete, but it covers many of the common cases. These are listed roughly 45: in order of decreasing difficulty for the average GCC user, meaning someone 46: who is not skilled in the internals of GCC, and where difficulty is measured 47: in terms of the time required to fix the bug. No alternative is better than 48: any other; each has its benefits and disadvantages. 49: * Fix it yourself. This alternative will probably bring results, if you 50: work hard enough, but will probably take a lot of time, and, depending 51: on the quality of your work and the perceived benefits of your changes, 52: your code may or may not ever make it into an official release of GCC. 53: * [27]Report the problem to the GCC bug tracking system and hope that 54: someone will be kind enough to fix it for you. While this is certainly 55: possible, and often happens, there is no guarantee that it will. You 56: should not expect the same response from this method that you would see 57: from a commercial support organization since the people who read GCC bug 58: reports, if they choose to help you, will be volunteering their time. 59: * Hire someone to fix it for you. There are various companies and 60: individuals providing support for GCC. This alternative costs money, but 61: is relatively likely to get results. 62: _________________________________________________________________ 63: 64: Does GCC work on my platform? 65: 66: The host/target specific installation notes for GCC include information 67: about known problems with installing or using GCC on particular platforms. 68: These are included in the sources for a release in INSTALL/specific.html, 69: and the [28]latest version is always available at the GCC web site. Reports 70: of [29]successful builds for several versions of GCC are also available at 71: the web site. 72: _________________________________________________________________ 73: 74: Installation 75: 76: How to install multiple versions of GCC 77: 78: It may be desirable to install multiple versions of the compiler on the same 79: system. This can be done by using different prefix paths at configure time 80: and a few symlinks. 81: 82: Basically, configure the two compilers with different --prefix options, then 83: build and install each compiler. Assume you want "gcc" to be the latest 84: compiler and available in /usr/local/bin; also assume that you want "gcc2" 85: to be the older gcc2 compiler and also available in /usr/local/bin. 86: 87: The easiest way to do this is to configure the new GCC with 88: --prefix=/usr/local/gcc and the older gcc2 with --prefix=/usr/local/gcc2. 89: Build and install both compilers. Then make a symlink from 90: /usr/local/bin/gcc to /usr/local/gcc/bin/gcc and from /usr/local/bin/gcc2 to 91: /usr/local/gcc2/bin/gcc. Create similar links for the "g++", "c++" and "g77" 92: compiler drivers. 93: 94: An alternative to using symlinks is to configure with a 95: --program-transform-name option. This option specifies a sed command to 96: process installed program names with. Using it you can, for instance, have 97: all the new GCC programs installed as "new-gcc" and the like. You will still 98: have to specify different --prefix options for new GCC and old GCC, because 99: it is only the executable program names that are transformed. The difference 100: is that you (as administrator) do not have to set up symlinks, but must 101: specify additional directories in your (as a user) PATH. A complication with 102: --program-transform-name is that the sed command invariably contains 103: characters significant to the shell, and these have to be escaped correctly, 104: also it is not possible to use "^" or "$" in the command. Here is the option 105: to prefix "new-" to the new GCC installed programs: 106: 107: --program-transform-name='s,\\\\(.*\\\\),new-\\\\1,' 108: 109: With the above --prefix option, that will install the new GCC programs into 110: /usr/local/gcc/bin with names prefixed by "new-". You can use 111: --program-transform-name if you have multiple versions of GCC, and wish to 112: be sure about which version you are invoking. 113: 114: If you use --prefix, GCC may have difficulty locating a GNU assembler or 115: linker on your system, [30]GCC can not find GNU as/GNU ld explains how to 116: deal with this. 117: 118: Another option that may be easier is to use the --program-prefix= or 119: --program-suffix= options to configure. So if you're installing GCC 2.95.2 120: and don't want to disturb the current version of GCC in /usr/local/bin/, you 121: could do 122: 123: configure --program-suffix=-2.95.2 <other configure options> 124: 125: This should result in GCC being installed as /usr/local/bin/gcc-2.95.2 126: instead of /usr/local/bin/gcc. 127: _________________________________________________________________ 128: 129: Dynamic linker is unable to find GCC libraries 130: 131: This problem manifests itself by programs not finding shared libraries they 132: depend on when the programs are started. Note this problem often manifests 133: itself with failures in the libio/libstdc++ tests after configuring with 134: --enable-shared and building GCC. 135: 136: GCC does not specify a runpath so that the dynamic linker can find dynamic 137: libraries at runtime. 138: 139: The short explanation is that if you always pass a -R option to the linker, 140: then your programs become dependent on directories which may be NFS mounted, 141: and programs may hang unnecessarily when an NFS server goes down. 142: 143: The problem is not programs that do require the directories; those programs 144: are going to hang no matter what you do. The problem is programs that do not 145: require the directories. 146: 147: SunOS effectively always passed a -R option for every -L option; this was a 148: bad idea, and so it was removed for Solaris. We should not recreate it. 149: 150: However, if you feel you really need such an option to be passed 151: automatically to the linker, you may add it to the GCC specs file. This file 152: can be found in the same directory that contains cc1 (run gcc 153: -print-prog-name=cc1 to find it). You may add linker flags such as -R or 154: -rpath, depending on platform and linker, to the *link or *lib specs. 155: 156: Another alternative is to install a wrapper script around gcc, g++ or ld 157: that adds the appropriate directory to the environment variable LD_RUN_PATH 158: or equivalent (again, it's platform-dependent). 159: 160: Yet another option, that works on a few platforms, is to hard-code the full 161: pathname of the library into its soname. This can only be accomplished by 162: modifying the appropriate .ml file within libstdc++/config (and also 163: libg++/config, if you are building libg++), so that $(libdir)/ appears just 164: before the library name in -soname or -h options. 165: _________________________________________________________________ 166: 167: GCC can not find GNU as/GNU ld 168: 169: GCC searches the PATH for an assembler and a loader, but it only does so 170: after searching a directory list hard-coded in the GCC executables. Since, 171: on most platforms, the hard-coded list includes directories in which the 172: system assembler and loader can be found, you may have to take one of the 173: following actions to arrange that GCC uses the GNU versions of those 174: programs. 175: 176: To ensure that GCC finds the GNU assembler (the GNU loader), which are 177: required by [31]some configurations, you should configure these with the 178: same --prefix option as you used for GCC. Then build & install GNU as (GNU 179: ld) and proceed with building GCC. 180: 181: Another alternative is to create links to GNU as and ld in any of the 182: directories printed by the command `gcc -print-search-dirs | grep 183: '^programs:''. The link to `ld' should be named `real-ld' if `ld' already 184: exists. If such links do not exist while you're compiling GCC, you may have 185: to create them in the build directories too, within the gcc directory and in 186: all the gcc/stage* subdirectories. 187: 188: GCC 2.95 allows you to specify the full pathname of the assembler and the 189: linker to use. The configure flags are `--with-as=/path/to/as' and 190: `--with-ld=/path/to/ld'. GCC will try to use these pathnames before looking 191: for `as' or `(real-)ld' in the standard search dirs. If, at configure-time, 192: the specified programs are found to be GNU utilities, `--with-gnu-as' and 193: `--with-gnu-ld' need not be used; these flags will be auto-detected. One 194: drawback of this option is that it won't allow you to override the search 195: path for assembler and linker with command-line options -B/path/ if the 196: specified filenames exist. 197: _________________________________________________________________ 198: 199: cpp: Usage:... Error 200: 201: If you get an error like this when building GCC (particularly when building 202: __mulsi3), then you likely have a problem with your environment variables. 203: cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp 204: [switches] input output 205: 206: First look for an explicit '.' in either LIBRARY_PATH or GCC_EXEC_PREFIX 207: from your environment. If you do not find an explicit '.', look for an empty 208: pathname in those variables. Note that ':' at either the start or end of 209: these variables is an implicit '.' and will cause problems. 210: 211: Also note '::' in these paths will also cause similar problems. 212: _________________________________________________________________ 213: 214: Optimizing the compiler itself 215: 216: If you want to test a particular optimization option, it's useful to try 217: bootstrapping the compiler with that option turned on. For example, to test 218: the -fssa option, you could bootstrap like this: 219: make BOOT_CFLAGS="-O2 -fssa" bootstrap 220: _________________________________________________________________ 221: 222: Why does libiconv get linked into jc1 on Solaris? 223: 224: The Java front end requires iconv. If the compiler used to bootstrap GCC 225: finds libiconv (because the GNU version of libiconv has been installed in 226: the same prefix as the bootstrap compiler), but the newly built GCC does not 227: find the library (because it will be installed with a different prefix), 228: then a link-time error will occur when building jc1. This problem does not 229: show up so often on platforms that have libiconv in a default location (like 230: /usr/lib) because then both compilers can find a library named libiconv, 231: even though it is a different library. 232: 233: Using --disable-nls at configure-time does not prevent this problem because 234: jc1 uses iconv even in that case. Solutions include temporarily removing the 235: GNU libiconv, copying it to a default location such as /usr/lib/, and using 236: --enable-languages at configure-time to disable Java. 237: _________________________________________________________________ 238: 239: Testsuite problems 240: 241: How do I pass flags like -fnew-abi to the testsuite? 242: 243: If you invoke runtest directly, you can use the --tool_opts option, e.g: 244: runtest --tool_opts "-fnew-abi -fno-honor-std" <other options> 245: 246: Or, if you use make check you can use the make variable RUNTESTFLAGS, e.g: 247: make RUNTESTFLAGS="--tool_opts '-fnew-abi -fno-honor-std'" check-g++ 248: _________________________________________________________________ 249: 250: How can I run the test suite with multiple options? 251: 252: If you invoke runtest directly, you can use the --target_board option, e.g: 253: runtest --target_board "unix{-fPIC,-fpic,}" <other options> 254: 255: Or, if you use make check you can use the make variable RUNTESTFLAGS, e.g: 256: make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-gcc 257: 258: Either of these examples will run the tests three times. Once with -fPIC, 259: once with -fpic, and once with no additional flags. 260: 261: This technique is particularly useful on multilibbed targets. 262: _________________________________________________________________ 263: 264: Miscellaneous 265: 266: Friend Templates 267: 268: In order to make a specialization of a template function a friend of a 269: (possibly template) class, you must explicitly state that the friend 270: function is a template, by appending angle brackets to its name, and this 271: template function must have been declared already. Here's an example: 272: template <typename T> class foo { 273: friend void bar(foo<T>); 274: } 275: 276: The above declaration declares a non-template function named bar, so it must 277: be explicitly defined for each specialization of foo. A template definition 278: of bar won't do, because it is unrelated with the non-template declaration 279: above. So you'd have to end up writing: 280: void bar(foo<int>) { /* ... */ } 281: void bar(foo<void>) { /* ... */ } 282: 283: If you meant bar to be a template function, you should have forward-declared 284: it as follows. Note that, since the template function declaration refers to 285: the template class, the template class must be forward-declared too: 286: template <typename T> 287: class foo; 288: 289: template <typename T> 290: void bar(foo<T>); 291: 292: template <typename T> 293: class foo { 294: friend void bar<>(foo<T>); 295: }; 296: 297: template <typename T> 298: void bar(foo<T>) { /* ... */ } 299: 300: In this case, the template argument list could be left empty, because it can 301: be implicitly deduced from the function arguments, but the angle brackets 302: must be present, otherwise the declaration will be taken as a non-template 303: function. Furthermore, in some cases, you may have to explicitly specify the 304: template arguments, to remove ambiguity. 305: 306: An error in the last public comment draft of the ANSI/ISO C++ Standard and 307: the fact that previous releases of GCC would accept such friend declarations 308: as template declarations has led people to believe that the forward 309: declaration was not necessary, but, according to the final version of the 310: Standard, it is. 311: _________________________________________________________________ 312: 313: dynamic_cast, throw, typeid don't work with shared libraries 314: 315: The new C++ ABI in the GCC 3.0 series uses address comparisons, rather than 316: string compares, to determine type equality. This leads to better 317: performance. Like other objects that have to be present in the final 318: executable, these std::type_info objects have what is called vague linkage 319: because they are not tightly bound to any one particular translation unit 320: (object file). The compiler has to emit them in any translation unit that 321: requires their presence, and then rely on the linking and loading process to 322: make sure that only one of them is active in the final executable. With 323: static linking all of these symbols are resolved at link time, but with 324: dynamic linking, further resolution occurs at load time. You have to ensure 325: that objects within a shared library are resolved against objects in the 326: executable and other shared libraries. 327: * For a program which is linked against a shared library, no additional 328: precautions are needed. 329: * You cannot create a shared library with the "-Bsymbolic" option, as that 330: prevents the resolution described above. 331: * If you use dlopen to explicitly load code from a shared library, you 332: must do several things. First, export global symbols from the executable 333: by linking it with the "-E" flag (you will have to specify this as 334: "-Wl,-E" if you are invoking the linker in the usual manner from the 335: compiler driver, g++). You must also make the external symbols in the 336: loaded library available for subsequent libraries by providing the 337: RTLD_GLOBAL flag to dlopen. The symbol resolution can be immediate or 338: lazy. 339: 340: Template instantiations are another, user visible, case of objects with 341: vague linkage, which needs similar resolution. If you do not take the above 342: precautions, you may discover that a template instantiation with the same 343: argument list, but instantiated in multiple translation units, has several 344: addresses, depending in which translation unit the address is taken. (This 345: is not an exhaustive list of the kind of objects which have vague linkage 346: and are expected to be resolved during linking & loading.) 347: 348: If you are worried about different objects with the same name colliding 349: during the linking or loading process, then you should use namespaces to 350: disambiguate them. Giving distinct objects with global linkage the same name 351: is a violation of the One Definition Rule (ODR) [basic.def.odr]. 352: 353: For more details about the way that GCC implements these and other C++ 354: features, please read the [32]ABI specification. Note the std::type_info 355: objects which must be resolved all begin with "_ZTS". Refer to ld's 356: documentation for a description of the "-E" & "-Bsymbolic" flags. 357: _________________________________________________________________ 358: 359: Why do I need autoconf, bison, xgettext, automake, etc? 360: 361: If you're using diffs up dated from one snapshot to the next, or if you're 362: using the SVN repository, you may need several additional programs to build 363: GCC. 364: 365: These include, but are not necessarily limited to autoconf, automake, bison, 366: and xgettext. 367: 368: This is necessary because neither diff nor cvs keep timestamps correct. This 369: causes problems for generated files as "make" may think those generated 370: files are out of date and try to regenerate them. 371: 372: An easy way to work around this problem is to use the gcc_update script in 373: the contrib subdirectory of GCC, which handles this transparently without 374: requiring installation of any additional tools. 375: 376: When building from diffs or SVN or if you modified some sources, you may 377: also need to obtain development versions of some GNU tools, as the 378: production versions do not necessarily handle all features needed to rebuild 379: GCC. 380: 381: In general, the current versions of these tools from 382: [33]ftp://ftp.gnu.org/gnu/ will work. At present, Autoconf 2.50 is not 383: supported, and you will need to use Autoconf 2.13; work is in progress to 384: fix this problem. Also look at [34]ftp://gcc.gnu.org/pub/gcc/infrastructure/ 385: for any special versions of packages. 386: _________________________________________________________________ 387: 388: Why can't I build a shared library? 389: 390: When building a shared library you may get an error message from the linker 391: like `assert pure-text failed:' or `DP relative code in file'. 392: 393: This kind of error occurs when you've failed to provide proper flags to gcc 394: when linking the shared library. 395: 396: You can get this error even if all the .o files for the shared library were 397: compiled with the proper PIC option. When building a shared library, gcc 398: will compile additional code to be included in the library. That additional 399: code must also be compiled with the proper PIC option. 400: 401: Adding the proper PIC option (-fpic or -fPIC) to the link line which creates 402: the shared library will fix this problem on targets that support PIC in this 403: manner. For example: 404: gcc -c -fPIC myfile.c 405: gcc -shared -o libmyfile.so -fPIC myfile.o 406: _________________________________________________________________ 407: 408: When building C++, the linker says my constructors, destructors or virtual 409: tables are undefined, but I defined them 410: 411: The ISO C++ Standard specifies that all virtual methods of a class that are 412: not pure-virtual must be defined, but does not require any diagnostic for 413: violations of this rule [class.virtual]/8. Based on this assumption, GCC 414: will only emit the implicitly defined constructors, the assignment operator, 415: the destructor and the virtual table of a class in the translation unit that 416: defines its first such non-inline method. 417: 418: Therefore, if you fail to define this particular method, the linker may 419: complain about the lack of definitions for apparently unrelated symbols. 420: Unfortunately, in order to improve this error message, it might be necessary 421: to change the linker, and this can't always be done. 422: 423: The solution is to ensure that all virtual methods that are not pure are 424: defined. Note that a destructor must be defined even if it is declared 425: pure-virtual [class.dtor]/7. 426: 427: References 428: 429: 1. http://gcc.gnu.org/faq.html 430: 2. http://c-faq.com/ 431: 3. http://www.comeaucomputing.com/csc/faq.html 432: 4. http://www.fortran.com/fortran/info.html 433: 5. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html 434: 6. http://gcc.gnu.org/java/faq.html 435: 7. http://gcc.gnu.org/faq.html#general 436: 8. http://gcc.gnu.org/faq.html#support 437: 9. http://gcc.gnu.org/faq.html#platforms 438: 10. http://gcc.gnu.org/faq.html#installation 439: 11. http://gcc.gnu.org/faq.html#multiple 440: 12. http://gcc.gnu.org/faq.html#rpath 441: 13. http://gcc.gnu.org/faq.html#rpath 442: 14. http://gcc.gnu.org/faq.html#gas 443: 15. http://gcc.gnu.org/faq.html#environ 444: 16. http://gcc.gnu.org/faq.html#optimizing 445: 17. http://gcc.gnu.org/faq.html#iconv 446: 18. http://gcc.gnu.org/faq.html#testsuite 447: 19. http://gcc.gnu.org/faq.html#testoptions 448: 20. http://gcc.gnu.org/faq.html#multipletests 449: 21. http://gcc.gnu.org/faq.html#misc 450: 22. http://gcc.gnu.org/faq.html#friend 451: 23. http://gcc.gnu.org/faq.html#dso 452: 24. http://gcc.gnu.org/faq.html#generated_files 453: 25. http://gcc.gnu.org/faq.html#picflag-needed 454: 26. http://gcc.gnu.org/faq.html#vtables 455: 27. http://gcc.gnu.org/bugs.html 456: 28. http://gcc.gnu.org/install/specific.html 457: 29. http://gcc.gnu.org/buildstat.html 458: 30. http://gcc.gnu.org/faq.html#gas 459: 31. http://gcc.gnu.org/install/specific.html 460: 32. http://www.codesourcery.com/cxx-abi/ 461: 33. ftp://ftp.gnu.org/gnu/ 462: 34. ftp://gcc.gnu.org/pub/gcc/infrastructure/