1 2 GCC Frequently Asked Questions 3 4 The latest version of this document is always available at 5 [1]http://www.gnu.org/software/gcc/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.lang.c++ FAQ, [4]comp.std.c++ FAQ, and the 10 [5]Fortran Information page. 11 _________________________________________________________________ 12 13 Questions 14 15 1. [6]General information 16 1. [7]What is the relationship between GCC and EGCS 17 2. [8]What is the relationship between GCC and Cygnus 18 3. [9]What is an open development model? 19 4. [10]How to report bugs 20 5. [11]How do I get a bug fixed or a feature added? 21 2. [12]Installation 22 1. [13]Problems building the Fortran compiler 23 2. [14]How to install multiple versions of GCC 24 3. [15]Dynamic linker is unable to find GCC libraries 25 4. [16]libstdc++/libio tests fail badly with --enable-shared 26 5. [17]GCC can not find GNU as/GNU ld 27 6. [18]cpp: Usage:... Error 28 3. [19]Testsuite problems 29 1. [20]Why is there no testsuite in GCC 2.95 30 2. [21]Unable to run the testsuite 31 3. [22]How do I pass flags like -fnew-abi to the testsuite? 32 4. [23]How can I run the test suite with multiple options? 33 4. [24]Platform-specific issues 34 1. [25]Problems with exception handling on x86 platforms 35 2. [26]Problems with Invalid `asm' statements 36 3. [27]Building Linux kernels 37 4. [28]How do I compile X11 headers with g++ 38 5. [29]How to build a cross compiler 39 5. [30]Bugs and Non-Bugs 40 1. [31]FD_ZERO macro 41 2. [32]Octave 2.0.13 does not compile 42 3. [33]Why can't I initialize a static variable with stdin? 43 4. [34]Why can't I use #if here? 44 6. [35]Miscellaneous 45 1. [36]Virtual memory exhausted 46 2. [37]Snapshots, how, when, why 47 3. [38]Friend Templates 48 4. [39]Where to find libg++ 49 5. [40]Why do I need autoconf, bison, xgettext, automake, etc 50 6. [41]Problems debugging GCC code 51 7. [42]Conflicts when using cvs update 52 8. [43]Using GCC with GNAT/Ada 53 9. [44]Using GCC with GNU Pascal 54 10. [45]Using CVS to download snapshots 55 11. [46]Why can't I build a shared library? 56 12. [47]Dealing with spam on the lists 57 13. [48]How to work around too long C++ symbol names? 58 (-fsquangle) 59 14. [49]When building from CVS sources, I see 'gperf: invalid 60 option -- F', even with the most current version of gperf. 61 15. [50]When building C++, the linker says my constructors, 62 destructors or virtual tables are undefined, but I defined 63 them 64 16. [51]What is libstdc++-v3 and how can I use it with g++? 65 _________________________________________________________________ 66 67 General information 68 69What is the relationship between GCC and EGCS 70 71 In 1990/1991 gcc version 1 had reached a point of stability. For the 72 targets it could support, it worked well. It had limitations inherent 73 in its design that would be difficult to resolve, so a major effort 74 was made to resolve those limitiations and gcc version 2 was the 75 result. 76 77 When we had gcc2 in a useful state, development efforts on gcc1 78 stopped and we all concentrated on making gcc2 better than gcc1 could 79 ever be. This is the kind of step forward we wanted to make with the 80 EGCS project when it was formed in 1997. 81 82 In April 1999 the Free Software Foundation officially halted 83 development on the gcc2 compiler and appointed the EGCS project as the 84 official GCC maintainers. 85 86 We are in the process of merging GCC and EGCS, which will take some 87 time. The net result will be a single project which will carry forward 88 GCC development under the ultimate control of the [52]GCC Steering 89 Committee. 90 _________________________________________________________________ 91 92What is the relationship between GCC and Cygnus 93 94 It is a common mis-conception that Cygnus controls either directly or 95 indirectly GCC. 96 97 While Cygnus does donate hardware, network connections, code and 98 developer time to GCC development, Cygnus does not control GCC. 99 100 Overall control of GCC is in the hands of the [53]GCC Steering 101 Committee which includes people from a variety of different 102 organizations and backgrounds. The purpose of the steering committee 103 is to make decisions in the best interest of GCC and to help ensure 104 that no individual or company has control over the project. 105 106 To summarize, Cygnus contributes to GCCproject, but does not exert a 107 controlling influence over GCC. 108 _________________________________________________________________ 109 110What is an open development model? 111 112 With GCC, we are going to try a bazaar style[54][1] approach to its 113 development: We make snapshots publicly available to anyone who wants 114 to try them; we're going to welcome anyone to join the development 115 mailing list. All of the discussions on the development mailing list 116 are available via the web. We're going to be making releases with a 117 much higher frequency than they have been made in the past. 118 119 In addition to weekly snapshots of the GCC development sources, we 120 have the sources readable from a CVS server by anyone. Furthermore we 121 are using remote CVS to allow remote maintainers write access to the 122 sources. 123 124 There have been many potential gcc developers who were not able to 125 participate in gcc development in the past. We want these people to 126 help in any way they can; we ultimately want GCC to be the best 127 compiler in the world. 128 129 A compiler is a complicated piece of software, there will still be 130 strong central maintainers who will reject patches, who will demand 131 documentation of implementations, and who will keep the level of 132 quality as high as it is today. Code that could use wider testing may 133 be integrated--code that is simply ill-conceived won't be. 134 135 GCC is not the first piece of software to use this open development 136 process; FreeBSD, the Emacs lisp repository, and the Linux kernel are 137 a few examples of the bazaar style of development. 138 139 With GCC, we will be adding new features and optimizations at a rate 140 that has not been done since the creation of gcc2; these additions 141 will inevitably have a temporarily destabilizing effect. With the help 142 of developers working together with this bazaar style development, the 143 resulting stability and quality levels will be better than we've had 144 before. 145 146 _[1]_ We've been discussing different development models a lot over 147 the past few months. The paper which started all of this introduced 148 two terms: A _cathedral_ development model versus a _bazaar_ 149 development model. The paper is written by Eric S. Raymond, it is 150 called ``[55]The Cathedral and the Bazaar''. The paper is a useful 151 starting point for discussions. 152 _________________________________________________________________ 153 154How to report bugs 155 156 There are complete instructions in the [56]gcc info manual, section 157 Bugs. The manual can also be read using `_M-x info_' in Emacs, or if 158 the GNU info program is installed on your system by `info --node 159 "(gcc)Bugs"'. Or see the file [57]BUGS included with the GCC source 160 code. 161 162 Before you report a bug for the _C++ compiler_, please check the 163 [58]list of well-known bugs. If you want to report a bug with _egcs 164 1.0.x_ or _egcs 1.1.x_, we strongly recommend upgrading to the current 165 release first. 166 167 In short, if GCC says Internal compiler error (or any other error that 168 you'd like us to be able to reproduce, for that matter), please mail a 169 bug report to [59]gcc-bugs@gcc.gnu.org or [60]bug-gcc@gnu.org 170 including: 171 * The GCC version 172 * The system type 173 * All options you passed to the compiler 174 * Preprocessed output of the source file that caused the compiler 175 error 176 177 All this can normally be accomplished by mailing the command line, the 178 output of the command, and the resulting `_your-file_.i' for C, or 179 `_your-file_.ii' for C++, corresponding to: 180 181 gcc -v --save-temps _all-your-options_ _your-file_.c 182 183 Typically the CPP output (extension .i for C or .ii for C++) will be 184 large, so please compress the resulting file with one of the popular 185 compression programs such as bzip2, gzip, zip, pkzip or compress (in 186 decreasing order of preference). Use maximum compression (-9) if 187 available. Please include the compressed CPP output in your bug 188 report. 189 190 Since we're supposed to be able to re-create the assembly output 191 (extension .s), you usually don't have to include it in the bug 192 report, although you may want to post parts of it to point out 193 assembly code you consider to be wrong. 194 195 Whether to use MIME attachments or uuencode is up to you. In any case, 196 make sure the compiler command line, version and error output are in 197 plain text, so that we don't have to decode the bug report in order to 198 tell who should take care of it. A meaningful subject indicating 199 language and platform also helps. 200 201 The gcc lists have message size limits (100 kbytes) and bug reports 202 over those limits will currently be bounced. We're trying to find a 203 way to allow larger bug reports to be posted, but this is currently 204 impossible (unless you use MIME partials, which most people are unable 205 to handle anyway, so you'd better avoid them for now). So, although we 206 prefer to have complete bug reports archived, if you cannot reduce the 207 bug report below the limit, please make it available for ftp or http 208 and post the URL. Another alternative is to break the preprocessed 209 output in multiple files (using split, for example) and post them in 210 separate messages, but we prefer to have self-contained bug reports in 211 single messages. 212 213 If you fail to supply enough information for a bug report to be 214 reproduced, someone will probably ask you to post additional 215 information (or just ignore your bug report, if they're in a bad day, 216 so try to get it right on the first posting :-). In this case, please 217 post the additional information to the bug reporting mailing list, not 218 just to the person who requested it, unless explicitly told so. If 219 possible, please include in this follow-up all the information you had 220 supplied in the incomplete bug report (including the preprocessor 221 output), so that the new bug report is self-contained. 222 _________________________________________________________________ 223 224How do I get a bug fixed or a feature added? 225 226 There are lots of ways to get something fixed. The list below may be 227 incomplete, but it covers many of the common cases. These are listed 228 roughly in order of increasing difficulty for the average GCC user, 229 meaning someone who is not skilled in the internals of GCC, and where 230 difficulty is measured in terms of the time required to fix the bug. 231 No alternative is better than any other; each has it's benefits and 232 disadvantages. 233 * Hire someone to fix it for you. There are various companies and 234 individuals providing support for GCC. This alternative costs 235 money, but is relatively likely to get results. 236 * Report the problem to gcc-bugs and hope that someone will be kind 237 enough to fix it for you. While this is certainly possible, and 238 often happens, there is no guarantee that it will. You should not 239 expect the same response from gcc-bugs that you would see from a 240 commercial support organization since the people who read 241 gcc-bugs, if they choose to help you, will be volunteering their 242 time. This alternative will work best if you follow the directions 243 on [61]submitting bugreports. 244 * Fix it yourself. This alternative will probably bring results, if 245 you work hard enough, but will probably take a lot of time, and, 246 depending on the quality of your work and the perceived benefits 247 of your changes, your code may or may not ever make it into an 248 official release of GCC. 249 _________________________________________________________________ 250 251 Installation 252 253Problems building the Fortran compiler 254 255 The Fortran front end can not be built with most vendor compilers; it 256 must be built with gcc. As a result, you may get an error if you do 257 not follow the install instructions carefully. 258 259 In particular, instead of using "make" to build GCC, you should use 260 "make bootstrap" if you are building a native compiler or "make cross" 261 if you are building a cross compiler. 262 263 It has also been reported that the Fortran compiler can not be built 264 on Red Hat 4.X GNU/Linux for the Alpha. Fixing this may require 265 upgrading binutils or to Red Hat 5.0; we'll provide more information 266 as it becomes available. 267 _________________________________________________________________ 268 269How to install multiple versions of gcc 270 271 It may be desirable to install multiple versions of the compiler on 272 the same system. This can be done by using different prefix paths at 273 configure time and a few symlinks. 274 275 Basically, configure the two compilers with different --prefix 276 options, then build and install each compiler. Assume you want "gcc" 277 to be the latest compiler and available in /usr/local/bin; also assume 278 that you want "gcc2" to be the older gcc2 compiler and also available 279 in /usr/local/bin. 280 281 The easiest way to do this is to configure the new GCC with 282 --prefix=/usr/local/gcc and the older gcc2 with 283 --prefix=/usr/local/gcc2. Build and install both compilers. Then make 284 a symlink from /usr/local/bin/gcc to /usr/local/gcc/bin/gcc and from 285 /usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar links 286 for the "g++", "c++" and "g77" compiler drivers. 287 288 An alternative to using symlinks is to configure with a 289 --program-transform-name option. This option specifies a sed command 290 to process installed program names with. Using it you can, for 291 instance, have all the new GCC programs installed as "new-gcc" and the 292 like. You will still have to specify different --prefix options for 293 new GCC and old GCC, because it is only the executable program names 294 that are transformed. The difference is that you (as administrator) do 295 not have to set up symlinks, but must specify additional directories 296 in your (as a user) PATH. A complication with --program-transform-name 297 is that the sed command invariably contains characters significant to 298 the shell, and these have to be escaped correctly, also it is not 299 possible to use "^" or "$" in the command. Here is the option to 300 prefix "new-" to the new GCC installed programs 301 "--program-transform-name='s,\\\\(.*\\\\),new-\\\\1,'". With the above 302 --prefix option, that will install the new GCC programs into 303 /usr/local/gcc/bin with names prefixed by "new-". You can use 304 --program-transform-name if you have multiple versions of GCC, and 305 wish to be sure about which version you are invoking. 306 307 If you use --prefix, GCC may have difficulty locating a GNU assembler 308 or linker on your system, [62]GCC can not find GNU as/GNU ld explains 309 how to deal with this. 310 _________________________________________________________________ 311 312Dynamic linker is unable to find GCC libraries 313 314 This problem manifests itself by programs not finding shared libraries 315 they depend on when the programs are started. Note this problem often 316 manifests itself with failures in the libio/libstdc++ tests after 317 configuring with --enable-shared and building GCC. 318 319 GCC does not specify a runpath so that the dynamic linker can find 320 dynamic libraries at runtime. 321 322 The short explanation is that if you always pass a -R option to the 323 linker, then your programs become dependent on directories which may 324 be NFS mounted, and programs may hang unnecessarily when an NFS server 325 goes down. 326 327 The problem is not programs that do require the directories; those 328 programs are going to hang no matter what you do. The problem is 329 programs that do not require the directories. 330 331 SunOS effectively always passed a -R option for every -L option; this 332 was a bad idea, and so it was removed for Solaris. We should not 333 recreate it. 334 335 However, if you feel you really need such an option to be passed 336 automatically to the linker, you may add it to the gcc specs file. 337 This file can be found in the same directory that contains cc1 (run 338 gcc -print-prog-name=cc1 to find it). You may add linker flags such as 339 -R or -rpath, depending on platform and linker, to the *link or *lib 340 specs. 341 342 Another alterative is to install a wrapper script around gcc, g++ or 343 ld that adds the appropriate directory to the environment variable 344 LD_RUN_PATH or equivalent (again, it's platform-dependent). 345 346 Yet another option, that works on a few platforms, is to hard-code the 347 full pathname of the library into its soname. This can only be 348 accomplished by modifying the appropriate .ml file within 349 libstdc++/config (and also libg++/config, if you are building libg++), 350 so that $(libdir)/ appears just before the library name in -soname or 351 -h options. 352 _________________________________________________________________ 353 354GCC can not find GNU as/GNU ld 355 356 GCC searches the PATH for an assembler and a loader, but it only does 357 so after searching a directory list hard-coded in the gcc executables. 358 Since, on most platforms, the hard-coded list includes directories in 359 which the system asembler and loader can be found, you may have to 360 take one of the following actions to arrange that gcc uses the GNU 361 versions of those programs. 362 363 To ensure that GCC finds the GNU assembler (the GNU loader), which are 364 required by [63]some configurations, you should configure these with 365 the same --prefix option as you used for GCC. Then build & install GNU 366 as (GNU ld) and proceed with building GCC. 367 368 Another alternative is to create links to GNU as and ld in any of the 369 directories printed by the command `gcc -print-search-dirs | grep 370 '^programs:''. The link to `ld' should be named `real-ld' if `ld' 371 already exists. If such links do not exist while you're compiling GCC, 372 you may have to create them in the build directories too, within the 373 gcc directory _and_ in all the gcc/stage* subdirectories. 374 375 GCC 2.95 allows you to specify the full pathname of the assembler and 376 the linker to use. The configure flags are `--with-as=/path/to/as' and 377 `--with-ld=/path/to/ld'. GCC will try to use these pathnames before 378 looking for `as' or `(real-)ld' in the standard search dirs. If, at 379 configure-time, the specified programs are found to be GNU utilities, 380 `--with-gnu-as' and `--with-gnu-ld' need not be used; these flags will 381 be auto-detected. One drawback of this option is that it won't allow 382 you to override the search path for assembler and linker with 383 command-line options -B/path/ if the specified filenames exist. 384 _________________________________________________________________ 385 386cpp: Usage:... Error 387 388 If you get an error like this when building GCC (particularly when 389 building __mulsi3), then you likely have a problem with your 390 environment variables. 391 cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp 392 [switches] input output 393 394 First look for an explicit '.' in either LIBRARY_PATH or 395 GCC_EXEC_PREFIX from your environment. If you do not find an explicit 396 '.', look for an empty pathname in those variables. Note that ':' at 397 either the start or end of these variables is an implicit '.' and will 398 cause problems. 399 400 Also note '::' in these paths will also cause similar problems. 401 _________________________________________________________________ 402 403 Testsuite problems 404 405Why is there no testsuite in GCC 2.95 406 407 The GCC testsuite is not included in the GCC 2.95 release due to the 408 uncertain copyright status of some tests. 409 410 The GCC team will be reviewing the entire testsuite to find and remove 411 any tests with uncertain copyright status. Once those tests are 412 removed from the testsuite, the testsuite as a whole will be 413 copyrighted under the terms of the GPL and included in future GCC 414 releases. 415 416 It is believed that only a few tests have uncertain copyright status 417 and thus only a few tests will need to be removed from the testsuite. 418 _________________________________________________________________ 419 420Unable to run the testsuite 421 422 If you get a message about unable to find "standard.exp" when trying 423 to run the GCC testsuites, then your dejagnu is too old to run the GCC 424 tests. You will need to get a newer version of dejagnu; we've made a 425 [64]dejagnu snapshot available until a new version of dejagnu can be 426 released. 427 _________________________________________________________________ 428 429How do I pass flags like -fnew-abi to the testsuite? 430 431 If you invoke runtest directly, you can use the --tool_opts option, 432 e.g: 433 runtest --tool_opts "-fnew-abi -fno-honor-std" <other options> 434 435 Or, if you use make check you can use the make variable RUNTESTFLAGS, 436 e.g: 437 make RUNTESTFLAGS='--tool_opts "-fnew-abi -fno-honor-std"' check-g++ 438 _________________________________________________________________ 439 440How can I run the test suite with multiple options? 441 442 If you invoke runtest directly, you can use the --target_board option, 443 e.g: 444 runtest --target_board "unix{-fPIC,-fpic,}" <other options> 445 446 Or, if you use make check you can use the make variable RUNTESTFLAGS, 447 e.g: 448 make RUNTESTFLAGS='--target_board "unix{-fPIC,-fpic,}"' check-gcc 449 450 Either of these examples will run the tests three times. Once with 451 -fPIC, once with -fpic, and once with no additional flags. 452 453 This technique is particularly useful on multilibbed targets. 454 _________________________________________________________________ 455 456 Platform-specific issues 457 458 Please read the [65]host/target specific installation notes, too. 459 460Problems with exception handling on x86 platforms 461 462 If you are using the GNU assembler (aka gas) on an x86 platform and 463 exception handling is not working correctly, then odds are you're 464 using a buggy assembler. Releases of binutils prior to 2.9 are known 465 to assemble exception handling code incorrectly. 466 467 We recommend binutils-2.9.1 or newer. Some post-2.9.1 snapshots of 468 binutils fix some subtle bugs, particularly on x86 and alpha. They are 469 available at [66]ftp://tsx-11.mit.edu/pub/linux/packages/GCC/. The 470 2.9.1.0.15 snapshot is known to work fine on those platforms; other 471 than that, be aware that snapshots are in general untested and may not 472 work (or even build). Use them at your own risk. 473 _________________________________________________________________ 474 475Problems with invalid `asm' statements 476 477 Previous releases of GCC (for example, GCC 2.7.2 or EGCS 1.1.2) did 478 not detect as invalid a clobber specifier that clobbered an operand. 479 Instead, it could spuriously and silently generate incorrect code for 480 certain non-obvious cases of source code. Even more unfortunately, the 481 manual (Using and Porting GCC, section Extended Asm, see the [67]bug 482 report entry) did not explicitly say that it was invalid to specify 483 clobber registers that were destined to overlap operands; it could 484 arguably be interpreted that it was correct to clobber an input 485 operand to mark it as not holding a usable value after the asm. 486 487 For the general case, there is no way to tell whether a specified 488 clobber is _intended_ to overlap with a specific (input) operand or is 489 a program error, where the choice of actual register for operands 490 failed to _avoid_ the clobbered register. Such unavoidable overlap is 491 detected by versions GCC 2.95 and newer, and flagged as an error 492 rather than accepted. An error message is given, such as: 493 foo.c: In function `foo': 494 foo.c:7: Invalid `asm' statement: 495 foo.c:7: fixed or forbidden register 0 (ax) was spilled for class AREG. 496 497 Unfortunately, a lot of existing software, for example the [68]Linux 498 kernel version 2.0.35 for the Intel x86, has constructs where input 499 operands are marked as clobbered. 500 501 The manual now describes how to write constructs with operands that 502 are modified by the construct, but not actually used. To write an asm 503 which modifies an input operand but does not output anything usable, 504 specify that operand as an _output operand_ outputting to an _unused 505 dummy variable_. 506 507 In the following example for the x86 architecture (taken from the 508 Linux 2.0.35 kernel -- include/asm-i386/delay.h), the register-class 509 constraint "a" denotes a register class containing the single register 510 "ax" (aka. "eax"). It is therefore invalid to clobber "ax"; this 511 operand has to be specified as an output as well as an input. The 512 following code is therefore _invalid_: 513extern __inline__ void 514__delay (int loops) 515{ 516 __asm__ __volatile__ 517 (".align 2,0x90\n1:\tdecl %0\n\tjns 1b" 518 : /* no outputs */ 519 : "a" (loops) 520 : "ax"); 521} 522 523 It could be argued that since the register class for "a" contains only 524 a single register, this could be detected as an "obvious" intended 525 clobber of the input operand. While that is feasible, it opens up for 526 further "obvious" cases, where the level of obviousness changes from 527 person to person. As there is a correct way to write such asm 528 constructs, this obviousness-detection is not needed other than for 529 reasons of compatibility with an existing code-base, and that code 530 base can be corrected. 531 532 This corrected and clobber-less version, is _valid_ for GCC 2.95 as 533 well as for previous versions of GCC and EGCS: 534extern __inline__ void 535__delay (int loops) 536{ 537 int dummy; 538 539 __asm__ __volatile__ 540 (".align 2,0x90\n1:\tdecl %0\n\tjns 1b" 541 : "=a" (dummy) 542 : "0" (loops)); 543} 544 545 Note that the asm construct now has an output operand, but it is 546 unused. Normally asm constructs with only unused output operands may 547 be removed by gcc, unless marked volatile as above. 548 _________________________________________________________________ 549 550Building Linux kernels 551 552 The linux kernel violates certain aliasing rules specified in the 553 ANSI/ISO standard. Starting with GCC 2.95, the gcc optimizer by 554 default relies on these rules to produce more efficient code and thus 555 will produce malfunctioning kernels. To work around this problem, the 556 flag -fno-strict-aliasing must be added to the CFLAGS variable in the 557 main kernel Makefile. 558 559 If you try to build a 2.0.x kernel for Intel machines with any 560 compiler other than GCC 2.7.2, then you are on your own. The 2.0.x 561 kernels are to be built only with gcc 2.7.2. They use certain asm 562 constructs which are incorrect, but (by accident) happen to work with 563 gcc 2.7.2. If you insist on building 2.0.x kernels with egcs, you may 564 be interested in this [69]patch which fixes some of the asm problems. 565 You will also want to change asm constructs to [70]avoid clobbering 566 their input operands. 567 568 If you installed a recent binutils/gas snapshot on your GNU/Linux 569 system, you may not be able to build the kernel because objdump does 570 not understand the "-k" switch. The solution for this problem is to 571 remove /usr/bin/encaps. (This is an obsolete program that was part of 572 older binutils distributions; the Linux kernel's Makefile looks for 573 this program to decide if you have an old or a new binutils. Problems 574 occur if you installed a new binutils but haven't removed encaps, 575 because the Makefile thinks you have the old one.) 576 577 Finally, you may get errors with the X driver of the form 578 _X11TransSocketUNIXConnect: Can't connect: errno = 111 579 580 This is a kernel bug. The function sys_iopl in 581 arch/i386/kernel/ioport.c does an illegal hack which used to work but 582 is now broken since GCC optimizes more aggressively . The newer 2.1.x 583 kernels already have a fix which should also work in 2.0.32. 584 _________________________________________________________________ 585 586How do I compile X11 headers with g++ 587 588 When compiling X11 headers with a GCC 2.95 or newer, g++ will complain 589 that types are missing. These headers assume that omitting the type 590 means 'int'; this assumption is wrong for C++. 591 592 g++ accepts such (illegal) constructs with the option -fpermissive; it 593 will assume that missing type is 'int' (as defined by the C89 594 standard). 595 596 Since the upcoming C99 standard also obsoletes the implicit type 597 assumptions, the X11 headers have to get fixed eventually. 598 _________________________________________________________________ 599 600How to build a cross compiler 601 602 Building cross compilers is a rather complex undertaking because they 603 usually need additional software (cross assembler, cross linker, 604 target libraries, target include files, etc). 605 606 We recommend reading the [71]crossgcc FAQ for information about 607 building cross compilers. 608 609 If you have all the pieces available, then `make cross' should build a 610 cross compiler. `make LANGUAGES="c c++" install' will install the 611 cross compiler. 612 613 Note that if you're trying to build a cross compiler in a tree which 614 includes binutils-2.8 in addition to GCC, then you're going to need to 615 make a couple minor tweaks so that the cross assembler, linker and nm 616 utilities will be found. 617 618 binutils-2.8 builds those files as gas.new, ld.new and nm.new; GCC 619 looks for them using gas-new, ld-new and nm-new, so you may have to 620 arrange for any symlinks which point to <file>.new to be changed to 621 <file>-new. 622 _________________________________________________________________ 623 624 Bugs and Non-Bugs 625 626 Unfortunately, improvements in tools that are widely used are sooner 627 or later bound to break _something_. Sometimes, the code that breaks 628 was wrong, and then that code should be fixed, even if it works for 629 earlier versions of gcc or other compilers. The following problems 630 with some releases of widely used packages have been identified: 631 632 There is a separate [72]list of well-known bugs describing known 633 deficiencies. Naturally we'd like that list to be of zero length. 634 635 To report a bug, see [73]How to report bugs. 636 _________________________________________________________________ 637 638FD_ZERO macro 639 640 The FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect. It uses 641 [74]invalid asm clobbers. The following rewrite by Ulrich Drepper 642 <drepper@cygnus.com> should fix this for glibc 2.0: 643 # define __FD_ZERO(fdsetp) \ 644 do { \ 645 int __d0, __d1; \ 646 __asm__ __volatile__ ("cld; rep; stosl" \ 647 : "=m" (((__fd_mask *) \ 648 (fdsetp))[__FDELT (__FD_SETSIZE)]), \ 649 "=&c" (__d0), "=&D" (__d1) \ 650 : "a" (0), "1" (sizeof (__fd_set) \ 651 / sizeof (__fd_mask)), \ 652 "2" ((__fd_mask *) (fdsetp)) \ 653 : "memory"); \ 654 } while (0) 655 _________________________________________________________________ 656 657Octave 2.0.13 does not compile 658 659 Apparently Octave 2.0.13 uses some C++ features which have been 660 obsoleted and thus fails to build with EGCS 1.1 and later. This 661 [75]patch to Octave should fix this. 662 663 Octave 2.0.13.96, a test release, has been compiled without patches by 664 egcs 1.1.2. It is available at 665 [76]ftp://ftp.che.wisc.edu/pub/octave/test-releases/. 666 _________________________________________________________________ 667 668Why can't I initialize a static variable with stdin? 669 670 This has nothing to do with gcc, but people ask us about it a lot. 671 Code like this: 672 #include <stdio.h> 673 674 FILE *yyin = stdin; 675 676 will not compile with GNU libc (Linux libc6), because stdin is not a 677 constant. This was done deliberately, in order for there to be no 678 limit on the number of open FILE objects. It is surprising for people 679 used to traditional Unix C libraries, but it is permitted by the C 680 standard. 681 682 This construct commonly occurs in code generated by old versions of 683 lex or yacc. We suggest you try regenerating the parser with a current 684 version of flex or bison, respectively. In your own code, the 685 appropriate fix is to move the initialization to the beginning of 686 main. 687 688 There is a common misconception that the GCC developers are 689 responsible for GNU libc. These are in fact two entirely separate 690 projects. The appropriate place to ask questions relating to GNU libc 691 is [77]libc-alpha@sourceware.cygnus.com. 692 _________________________________________________________________ 693 694Why can't I use #if here? 695 696 Let me guess... you wrote code that looks something like this: 697 memcpy(dest, src, 698#ifdef PLATFORM1 699 12 700#else 701 24 702#endif 703 ); 704 705 and you got a whole pile of error messages: 706test.c:11: warning: preprocessing directive not recognized within macro arg 707test.c:11: warning: preprocessing directive not recognized within macro arg 708test.c:11: warning: preprocessing directive not recognized within macro arg 709test.c: In function `foo': 710test.c:6: undefined or invalid # directive 711test.c:8: undefined or invalid # directive 712test.c:9: parse error before `24' 713test.c:10: undefined or invalid # directive 714test.c:11: parse error before `#' 715 716 The problem, simply put, is that GCC's preprocessor does not allow you 717 to put #ifdef (or any other directive) inside the arguments of a 718 macro. Your C library's string.h happens to define memcpy as a macro - 719 this is perfectly legitimate. The code therefore will not compile. 720 721 We have two good reasons for not allowing directives inside macro 722 arguments. First, it is not portable. It is "undefined behavior" 723 according to the C standard; that means different compilers will do 724 different things with it. Some will give you errors. Some will dump 725 core. Some will silently mangle your code - you could get the 726 equivalent of 727 memcpy(dest, src, 1224); 728 729 from the above example. A very few might do what you expected it to. 730 We therefore feel it is most useful for GCC to reject this construct 731 immediately so that it is found and fixed. 732 733 Second, it is extraordinarily difficult to implement the preprocessor 734 such that it does what you would expect for every possible directive 735 found inside a macro argument. The best example is perhaps 736#define foo(arg) ... arg ... 737foo(blah 738#undef foo 739blah) 740 741 which is impossible to implement in portable C without leaking memory. 742 Allowing only a subset of directives would be confusing. 743 744 It is always possible to rewrite code which uses conditionals inside 745 macros so that it doesn't. You could write the above example 746#ifdef PLATFORM1 747 memcpy(dest, src, 12); 748#else 749 memcpy(dest, src, 24); 750#endif 751 752 This is a bit more typing, but I personally think it's better style in 753 addition to being more portable. 754 _________________________________________________________________ 755 756 Miscellaneous 757 758Virtual memory exhausted error 759 760 This error means your system ran out of memory; this can happen for 761 large files, particularly when optimizing. If you're getting this 762 error you should consider trying to simplify your files or reducing 763 the optimization level. 764 765 Note that using -pedantic or -Wreturn-type can cause an explosion in 766 the amount of memory needed for template-heavy C++ code, such as code 767 that uses STL. Also note that -Wall includes -Wreturn-type, so if you 768 use -Wall you will need to specify -Wno-return-type to turn it off. 769 _________________________________________________________________ 770 771Snapshots, how, when, why 772 773 We make snapshots of the GCC sources about once a week; there is no 774 predetermined schedule. These snapshots are intended to give everyone 775 access to work in progress. Any given snapshot may generate incorrect 776 code or even fail to build. 777 778 If you plan on downloading and using snapshots, we highly recommend 779 you subscribe to the GCC mailing lists. See [78]mailing lists on the 780 main GCC page for instructions on how to subscribe. 781 782 When using the diff files to update from older snapshots to newer 783 snapshots, make sure to use "-E" and "-p" arguments to patch so that 784 empty files are deleted and full pathnames are provided to patch. If 785 your version of patch does not support "-E", you'll need to get a 786 newer version. Also note that you may need autoconf, autoheader and 787 various other programs if you use diff files to update from one 788 snapshot to the next. 789 _________________________________________________________________ 790 791Friend Templates 792 793 In order to make a specialization of a template function a friend of a 794 (possibly template) class, you must explicitly state that the friend 795 function is a template, by appending angle brackets to its name, and 796 this template function must have been declared already. Here's an 797 example: 798template <typename T> class foo { 799 friend void bar(foo<T>); 800} 801 802 The above declaration declares a non-template function named bar, so 803 it must be explicitly defined for _each_ specialization of foo. A 804 template definition of bar won't do, because it is unrelated with the 805 non-template declaration above. So you'd have to end up writing: 806void bar(foo<int>) { /* ... */ } 807void bar(foo<void>) { /* ... */ } 808 809 If you meant bar to be a template function, you should have 810 forward-declared it as follows. Note that, since the template function 811 declaration refers to the template class, the template class must be 812 forward-declared too: 813template <typename T> 814class foo; 815 816template <typename T> 817void bar(foo<T>); 818 819template <typename T> 820class foo { 821 friend void bar<>(foo<T>); 822}; 823 824template <typename T> 825void bar(foo<T>) { /* ... */ } 826 827 In this case, the template argument list could be left empty, because 828 it can be implicitly deduced from the function arguments, but the 829 angle brackets must be present, otherwise the declaration will be 830 taken as a non-template function. Furthermore, in some cases, you may 831 have to explicitly specify the template arguments, to remove 832 ambiguity. 833 834 An error in the last public comment draft of the ANSI/ISO C++ Standard 835 and the fact that previous releases of gcc would accept such friend 836 declarations as template declarations has led people to believe that 837 the forward declaration was not necessary, but, according to the final 838 version of the Standard, it is. 839 _________________________________________________________________ 840 841Where to find libg++ 842 843 Many folks have been asking where to find libg++ for GCC. First we 844 should point out that few programs actually need libg++; most only 845 need libstdc++/libio which are included in the GCC distribution. 846 847 If you do need libg++ you can get a libg++ release that works with GCC 848 from [79]ftp://egcs.cygnus.com/pub/egcs/infrastructure/. Note that the 849 2.8.2 snapshot pre-dates the 2.8.1.2 release. 850 _________________________________________________________________ 851 852autoconf, bison, xgettext, automake, etc 853 854 If you're using diffs up dated from one snapshot to the next, or if 855 you're using the CVS repository, you may need several additional 856 programs to build GCC. 857 858 These include, but are not necessarily limited to autoconf, automake, 859 bison, and xgettext. 860 861 This is necessary because neither diff nor cvs keep timestamps 862 correct. This causes problems for generated files as "make" may think 863 those generated files are out of date and try to regenerate them. 864 865 An easy way to work around this problem is to use the gcc_update 866 script in the contrib subdirectory of GCC, which handles this 867 transparently without requiring installation of any additional tools. 868 (Note: Up to and including GCC 2.95 this script was called egcs_update 869 .) 870 871 When building from diffs or CVS or if you modified some sources, you 872 may also need to obtain development versions of some GNU tools, as the 873 production versions do not necessarily handle all features needed to 874 rebuild GCC. 875 876 Autoconf is available from [80]http://sourceware.cygnus.com/autoconf/; 877 have a look at [81]ftp://egcs.cygnus.com/pub/egcs/infrastructure/ for 878 the other packages. 879 _________________________________________________________________ 880 881Conflicts when using cvs update 882 883 It is not uncommon to get CVS conflict messages for some generated 884 files when updating your local sources from the CVS repository. 885 Typically such conflicts occur with bison or autoconf generated files. 886 887 As long as you haven't been making modifications to the generated 888 files or the generator files, it is safe to delete the offending file, 889 then run cvs update again to get a new copy. 890 _________________________________________________________________ 891 892Problems debugging GCC code 893 894 On some systems GCC will produce dwarf debug records by default; 895 however the gdb-4.16 release may not be able to read such debug 896 records. 897 898 You can either use the argument "-gstabs" instead of "-g" or pick up a 899 copy of gdb-4.17 to work around the problem. 900 _________________________________________________________________ 901 902Using GCC with GNAT/Ada 903 904 The GNU Ada front-end is not currently supported by GCC; however, it 905 is possible to build the GNAT compiler with a little work. 906 907 First, retrieve the gnat-3.10p sources. The sources for the Ada front 908 end and runtime all live in the "ada" subdirectory. Move that 909 subdirectory to egcs/gcc/ada. 910 911 Second, apply the patch found in egcs/gcc/README.gnat. 912 913 Finally, rebuild per the GNAT build instructions. 914 _________________________________________________________________ 915 916Using GCC with GNU Pascal 917 918 The [82]GNU Pascal front-end does work with EGCS 1.1 It does not work 919 with EGCS 1.0.x and the main branch of the CVS repository. A tarball 920 can be found at 921 [83]ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/. 922 _________________________________________________________________ 923 924Using CVS to download snapshots 925 926 It is possible to checkout specific snapshots with CVS or to check out 927 the latest snapshot. 928 929 We use CVS tags to identify each snapshot we make. Snapshot tags have 930 the form "egcs_ss_YYYYMMDD". In addition, the latest official snapshot 931 always has the tag "gcc_latest_snapshot". 932 _________________________________________________________________ 933 934Why can't I build a shared library? 935 936 When building a shared library you may get an error message from the 937 linker like `assert pure-text failed:' or `DP relative code in file'. 938 939 This kind of error occurs when you've failed to provide proper flags 940 to gcc when linking the shared library. 941 942 You can get this error even if all the .o files for the shared library 943 were compiled with the proper PIC option. When building a shared 944 library, gcc will compile additional code to be included in the 945 library. That additional code must also be compiled with the proper 946 PIC option. 947 948 Adding the proper PIC option (-fpic or -fPIC) to the link line which 949 creates the shared library will fix this problem on targets that 950 support PIC in this manner. For example: 951 gcc -c -fPIC myfile.c 952 gcc -shared -o libmyfile.so -fPIC myfile.o 953 _________________________________________________________________ 954 955How to work around too long C++ symbol names? (-fsquangle) 956 957 If the standard assembler of your platform can't cope with the large 958 symbol names that the default g++ name mangling mechanism produces, 959 your best bet is to use GNU as, from the GNU binutils package. 960 961 Unfortunately, GNU as does not support all platforms supported by 962 egcs, so you may have to use an experimental work-around: the 963 -fsquangle option, that enables compression of symbol names. 964 965 Note that this option is still under development, and subject to 966 change. Since it modifies the name mangling mechanism, you'll need to 967 build libstdc++ and any other C++ libraries with this option enabled. 968 Furthermore, if this option changes its behavior in the future, you'll 969 have to rebuild them all again. :-( 970 971 This option can be enabled by default by initializing 972 `flag_do_squangling' with `1' in `gcc/cp/decl2.c' (it is not 973 initialized by default), then rebuilding egcs and any C++ libraries. 974 _________________________________________________________________ 975 976When building from CVS sources, I see 'gperf: invalid option -- F', even with 977the most current version of gperf. 978 979 The current version of gperf (v2.7) does not support the -F flag which 980 is used when building egcs from CVS sources. You will need to obtain a 981 patch for gperf and rebuild the program; this patch is available at 982 [84]ftp://egcs.cygnus.com/pub/egcs/infrastructure/ 983 984 Patches for other tools, particularly autoconf, may also be necessary 985 if you're building from CVS sources. Please see the [85]FAQ entry 986 regarding these tools to determine if anything else is needed. 987 988 These patched utilities should _only_ be required if you are building 989 from CVS sources. For example, gperf is used to generate C code for a 990 perfect hash function given an input file. Distributions of egcs 991 already contain the generated C code, while the CVS sources will 992 provide only the gperf input file. So gperf should only be necessary 993 if you are building anything obtained from CVS. 994 _________________________________________________________________ 995 996When building C++, the linker says my constructors, destructors or virtual 997tables are undefined, but I defined them 998 999 The ISO C++ Standard specifies that all virtual methods of a class 1000 that are not pure-virtual must be defined, but does not require any 1001 diagnostic for violations of this rule [class.virtual]/8. Based on 1002 this assumption, egcs will only emit the implicitly defined 1003 constructors, the assignment operator, the destructor and the virtual 1004 table of a class in the translation unit that defines its first such 1005 non-inline method. 1006 1007 Therefore, if you fail to define this particular method, the linker 1008 may complain about the lack of definitions for apparently unrelated 1009 symbols. Unfortunately, in order to improve this error message, it 1010 might be necessary to change the linker, and this can't always be 1011 done. 1012 1013 The solution is to ensure that all virtual methods that are not pure 1014 are defined. Note that a destructor must be defined even if it is 1015 declared pure-virtual [class.dtor]/7. 1016 _________________________________________________________________ 1017 1018What is libstdc++-v3 and how can I use it with g++? 1019 1020 From the [86]libstdc++-FAQ: "The EGCS Standard C++ Library v3, or 1021 libstdc++-2.90.x, is an ongoing project to implement the ISO 14882 1022 Standard C++ library as described in chapters 17 through 27 and annex 1023 D." 1024 1025 At the moment the libstdc++-v3 is no "drop in replacement" for GCC's 1026 libstdc++. The best way to use it is as follows: 1027 1. Build and install GCC 1028 2. Build and install libstdc++-v3 1029 3. Use compiler flags to use the new libstdc++ 1030 1031 Please note that the libstdc++-v3 is not yet complete and should only 1032 be used by experienced programmers. 1033 1034 For more information please refer to the [87]libstdc++-v3 homepage 1035 _________________________________________________________________ 1036 1037 [88]Return to the GCC home page 1038 1039 _Last modified: October 19, 1999_ 1040 1041References 1042 1043 1. http://www.gnu.org/software/gcc/faq.html 1044 2. http://www.eskimo.com/~scs/C-faq/top.html 1045 3. http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/ 1046 4. http://reality.sgi.com/austern_mti/std-c++/faq.html 1047 5. http://www.fortran.com/fortran/info.html 1048 6. http://gcc.gnu.org/faq.html#general 1049 7. http://gcc.gnu.org/faq.html#gcc 1050 8. http://gcc.gnu.org/faq.html#cygnus 1051 9. http://gcc.gnu.org/faq.html#open-development 1052 10. http://gcc.gnu.org/faq.html#bugreport 1053 11. http://gcc.gnu.org/faq.html#support 1054 12. http://gcc.gnu.org/faq.html#installation 1055 13. http://gcc.gnu.org/faq.html#fortran 1056 14. http://gcc.gnu.org/faq.html#multiple 1057 15. http://gcc.gnu.org/faq.html#rpath 1058 16. http://gcc.gnu.org/faq.html#rpath 1059 17. http://gcc.gnu.org/faq.html#gas 1060 18. http://gcc.gnu.org/faq.html#environ 1061 19. http://gcc.gnu.org/faq.html#testsuite 1062 20. http://gcc.gnu.org/faq.html#testsuite 1063 21. http://gcc.gnu.org/faq.html#dejagnu 1064 22. http://gcc.gnu.org/faq.html#testoptions 1065 23. http://gcc.gnu.org/faq.html#multipletests 1066 24. http://gcc.gnu.org/faq.html#platform 1067 25. http://gcc.gnu.org/faq.html#x86eh 1068 26. http://gcc.gnu.org/faq.html#asmclobber 1069 27. http://gcc.gnu.org/faq.html#linuxkernel 1070 28. http://gcc.gnu.org/faq.html#X11R6 1071 29. http://gcc.gnu.org/faq.html#cross 1072 30. http://gcc.gnu.org/faq.html#bugs 1073 31. http://gcc.gnu.org/faq.html#fdzero 1074 32. http://gcc.gnu.org/faq.html#octave 1075 33. http://gcc.gnu.org/faq.html#stdin 1076 34. http://gcc.gnu.org/faq.html#macarg 1077 35. http://gcc.gnu.org/faq.html#misc 1078 36. http://gcc.gnu.org/faq.html#memexhausted 1079 37. http://gcc.gnu.org/faq.html#snapshot 1080 38. http://gcc.gnu.org/faq.html#friend 1081 39. http://gcc.gnu.org/faq.html#libg++ 1082 40. http://gcc.gnu.org/faq.html#generated_files 1083 41. http://gcc.gnu.org/faq.html#gdb 1084 42. http://gcc.gnu.org/faq.html#conflicts 1085 43. http://gcc.gnu.org/faq.html#gnat 1086 44. http://gcc.gnu.org/faq.html#gpc 1087 45. http://gcc.gnu.org/faq.html#cvssnapshots 1088 46. http://gcc.gnu.org/faq.html#picflag-needed 1089 47. http://gcc.gnu.org/spam.html 1090 48. http://gcc.gnu.org/faq.html#squangle 1091 49. http://gcc.gnu.org/faq.html#gperf 1092 50. http://gcc.gnu.org/faq.html#vtables 1093 51. http://gcc.gnu.org/faq.html#libstdc++ 1094 52. http://gcc.gnu.org/steering.html 1095 53. http://gcc.gnu.org/steering.html 1096 54. http://gcc.gnu.org/faq.html#cathedral-vs-bazaar 1097 55. http://locke.ccil.org/~esr/writings/cathedral.html 1098 56. http://gcc.gnu.org/onlinedocs/ 1099 57. http://egcs.cygnus.com/cgi-bin/cvsweb.cgi/~checkout~/egcs/gcc/BUGS?content-type=text/plain&only_with_tag=HEAD 1100 58. http://gcc.gnu.org/bugs.html 1101 59. mailto:gcc-bugs@gcc.gnu.org 1102 60. mailto:bug-gcc@gnu.org 1103 61. http://gcc.gnu.org/faq.html#bugreport 1104 62. http://gcc.gnu.org/faq.html#gas 1105 63. http://gcc.gnu.org/install/specific.html 1106 64. ftp://egcs.cygnus.com/pub/egcs/infrastructure/dejagnu-19981026.tar.gz 1107 65. http://gcc.gnu.org/install/specific.html 1108 66. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ 1109 67. http://gcc.gnu.org/faq.html#bugreport 1110 68. http://gcc.gnu.org/faq.html#linuxkernel 1111 69. http://www.suse.de/~florian/kernel+egcs.html 1112 70. http://gcc.gnu.org/faq.html#asmclobber 1113 71. http://www.objsw.com/CrossGCC/ 1114 72. http://gcc.gnu.org/bugs.html 1115 73. http://gcc.gnu.org/faq.html#bugreport 1116 74. http://gcc.gnu.org/faq.html#asmclobber 1117 75. http://www.che.wisc.edu/octave/mailing-lists/bug-octave/1998/270 1118 76. ftp://ftp.che.wisc.edu/pub/octave/test-releases/ 1119 77. mailto:libc-alpha@sourceware.cygnus.com 1120 78. http://gcc.gnu.org/index.html#mailinglists 1121 79. ftp://egcs.cygnus.com/pub/egcs/infrastructure/ 1122 80. http://sourceware.cygnus.com/autoconf/ 1123 81. ftp://egcs.cygnus.com/pub/egcs/infrastructure/ 1124 82. http://home.pages.de/~GNU-Pascal/ 1125 83. ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ 1126 84. ftp://egcs.cygnus.com/pub/egcs/infrastructure 1127 85. http://gcc.gnu.org/faq.html#generated_files 1128 86. http://sourceware.cygnus.com/libstdc++/faq/ 1129 87. http://sourceware.cygnus.com/libstdc++/ 1130 88. http://gcc.gnu.org/index.html 1131