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