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