GCC Frequently Asked QuestionsThe latest version of this document is always available at[1]http://www.gnu.org/software/gcc/faq.html.This FAQ tries to answer specific questions concerning GCC. Forgeneral information regarding C, C++, resp. Fortran please check the[2]comp.lang.c FAQ, [3]comp.lang.c++ FAQ, [4]comp.std.c++ FAQ, and the[5]Fortran Information page._________________________________________________________________Questions1. [6]General information1. [7]What is the relationship between GCC and EGCS2. [8]What is the relationship between GCC and Cygnus3. [9]What is an open development model?4. [10]How to report bugs5. [11]How do I get a bug fixed or a feature added?2. [12]Installation1. [13]Problems building the Fortran compiler2. [14]How to install multiple versions of GCC3. [15]Dynamic linker is unable to find GCC libraries4. [16]libstdc++/libio tests fail badly with --enable-shared5. [17]GCC can not find GNU as/GNU ld6. [18]cpp: Usage:... Error3. [19]Testsuite problems1. [20]Why is there no testsuite in GCC 2.952. [21]Unable to run the testsuite3. [22]How do I pass flags like -fnew-abi to the testsuite?4. [23]How can I run the test suite with multiple options?4. [24]Platform-specific issues1. [25]Problems with exception handling on x86 platforms2. [26]Problems with Invalid `asm' statements3. [27]Building Linux kernels4. [28]How do I compile X11 headers with g++5. [29]How to build a cross compiler5. [30]Bugs and Non-Bugs1. [31]FD_ZERO macro2. [32]Octave 2.0.13 does not compile3. [33]Why can't I initialize a static variable with stdin?4. [34]Why can't I use #if here?6. [35]Miscellaneous1. [36]Virtual memory exhausted2. [37]Snapshots, how, when, why3. [38]Friend Templates4. [39]Where to find libg++5. [40]Why do I need autoconf, bison, xgettext, automake, etc6. [41]Problems debugging GCC code7. [42]Conflicts when using cvs update8. [43]Using GCC with GNAT/Ada9. [44]Using GCC with GNU Pascal10. [45]Using CVS to download snapshots11. [46]Why can't I build a shared library?12. [47]Dealing with spam on the lists13. [48]How to work around too long C++ symbol names?(-fsquangle)14. [49]When building from CVS sources, I see 'gperf: invalidoption -- F', even with the most current version of gperf.15. [50]When building C++, the linker says my constructors,destructors or virtual tables are undefined, but I definedthem16. [51]What is libstdc++-v3 and how can I use it with g++?_________________________________________________________________General informationWhat is the relationship between GCC and EGCSIn 1990/1991 gcc version 1 had reached a point of stability. For thetargets it could support, it worked well. It had limitations inherentin its design that would be difficult to resolve, so a major effortwas made to resolve those limitiations and gcc version 2 was theresult.When we had gcc2 in a useful state, development efforts on gcc1stopped and we all concentrated on making gcc2 better than gcc1 couldever be. This is the kind of step forward we wanted to make with theEGCS project when it was formed in 1997.In April 1999 the Free Software Foundation officially halteddevelopment on the gcc2 compiler and appointed the EGCS project as theofficial GCC maintainers.We are in the process of merging GCC and EGCS, which will take sometime. The net result will be a single project which will carry forwardGCC development under the ultimate control of the [52]GCC SteeringCommittee._________________________________________________________________What is the relationship between GCC and CygnusIt is a common mis-conception that Cygnus controls either directly orindirectly GCC.While Cygnus does donate hardware, network connections, code anddeveloper time to GCC development, Cygnus does not control GCC.Overall control of GCC is in the hands of the [53]GCC SteeringCommittee which includes people from a variety of differentorganizations and backgrounds. The purpose of the steering committeeis to make decisions in the best interest of GCC and to help ensurethat no individual or company has control over the project.To summarize, Cygnus contributes to GCCproject, but does not exert acontrolling influence over GCC._________________________________________________________________What is an open development model?With GCC, we are going to try a bazaar style[54][1] approach to itsdevelopment: We make snapshots publicly available to anyone who wantsto try them; we're going to welcome anyone to join the developmentmailing list. All of the discussions on the development mailing listare available via the web. We're going to be making releases with amuch higher frequency than they have been made in the past.In addition to weekly snapshots of the GCC development sources, wehave the sources readable from a CVS server by anyone. Furthermore weare using remote CVS to allow remote maintainers write access to thesources.There have been many potential gcc developers who were not able toparticipate in gcc development in the past. We want these people tohelp in any way they can; we ultimately want GCC to be the bestcompiler in the world.A compiler is a complicated piece of software, there will still bestrong central maintainers who will reject patches, who will demanddocumentation of implementations, and who will keep the level ofquality as high as it is today. Code that could use wider testing maybe integrated--code that is simply ill-conceived won't be.GCC is not the first piece of software to use this open developmentprocess; FreeBSD, the Emacs lisp repository, and the Linux kernel area few examples of the bazaar style of development.With GCC, we will be adding new features and optimizations at a ratethat has not been done since the creation of gcc2; these additionswill inevitably have a temporarily destabilizing effect. With the helpof developers working together with this bazaar style development, theresulting stability and quality levels will be better than we've hadbefore._[1]_ We've been discussing different development models a lot overthe past few months. The paper which started all of this introducedtwo terms: A _cathedral_ development model versus a _bazaar_development model. The paper is written by Eric S. Raymond, it iscalled ``[55]The Cathedral and the Bazaar''. The paper is a usefulstarting point for discussions._________________________________________________________________How to report bugsThere are complete instructions in the [56]gcc info manual, sectionBugs. The manual can also be read using `_M-x info_' in Emacs, or ifthe GNU info program is installed on your system by `info --node"(gcc)Bugs"'. Or see the file [57]BUGS included with the GCC sourcecode.Before you report a bug for the _C++ compiler_, please check the[58]list of well-known bugs. If you want to report a bug with _egcs1.0.x_ or _egcs 1.1.x_, we strongly recommend upgrading to the currentrelease first.In short, if GCC says Internal compiler error (or any other error thatyou'd like us to be able to reproduce, for that matter), please mail abug report to [59]gcc-bugs@gcc.gnu.org or [60]bug-gcc@gnu.orgincluding:* The GCC version* The system type* All options you passed to the compiler* Preprocessed output of the source file that caused the compilererrorAll this can normally be accomplished by mailing the command line, theoutput of the command, and the resulting `_your-file_.i' for C, or`_your-file_.ii' for C++, corresponding to:gcc -v --save-temps _all-your-options_ _your-file_.cTypically the CPP output (extension .i for C or .ii for C++) will belarge, so please compress the resulting file with one of the popularcompression programs such as bzip2, gzip, zip, pkzip or compress (indecreasing order of preference). Use maximum compression (-9) ifavailable. Please include the compressed CPP output in your bugreport.Since we're supposed to be able to re-create the assembly output(extension .s), you usually don't have to include it in the bugreport, although you may want to post parts of it to point outassembly code you consider to be wrong.Whether to use MIME attachments or uuencode is up to you. In any case,make sure the compiler command line, version and error output are inplain text, so that we don't have to decode the bug report in order totell who should take care of it. A meaningful subject indicatinglanguage and platform also helps.The gcc lists have message size limits (100 kbytes) and bug reportsover those limits will currently be bounced. We're trying to find away to allow larger bug reports to be posted, but this is currentlyimpossible (unless you use MIME partials, which most people are unableto handle anyway, so you'd better avoid them for now). So, although weprefer to have complete bug reports archived, if you cannot reduce thebug report below the limit, please make it available for ftp or httpand post the URL. Another alternative is to break the preprocessedoutput in multiple files (using split, for example) and post them inseparate messages, but we prefer to have self-contained bug reports insingle messages.If you fail to supply enough information for a bug report to bereproduced, someone will probably ask you to post additionalinformation (or just ignore your bug report, if they're in a bad day,so try to get it right on the first posting :-). In this case, pleasepost the additional information to the bug reporting mailing list, notjust to the person who requested it, unless explicitly told so. Ifpossible, please include in this follow-up all the information you hadsupplied in the incomplete bug report (including the preprocessoroutput), so that the new bug report is self-contained._________________________________________________________________How do I get a bug fixed or a feature added?There are lots of ways to get something fixed. The list below may beincomplete, but it covers many of the common cases. These are listedroughly in order of increasing difficulty for the average GCC user,meaning someone who is not skilled in the internals of GCC, and wheredifficulty is measured in terms of the time required to fix the bug.No alternative is better than any other; each has it's benefits anddisadvantages.* Hire someone to fix it for you. There are various companies andindividuals providing support for GCC. This alternative costsmoney, but is relatively likely to get results.* Report the problem to gcc-bugs and hope that someone will be kindenough to fix it for you. While this is certainly possible, andoften happens, there is no guarantee that it will. You should notexpect the same response from gcc-bugs that you would see from acommercial support organization since the people who readgcc-bugs, if they choose to help you, will be volunteering theirtime. This alternative will work best if you follow the directionson [61]submitting bugreports.* Fix it yourself. This alternative will probably bring results, ifyou work hard enough, but will probably take a lot of time, and,depending on the quality of your work and the perceived benefitsof your changes, your code may or may not ever make it into anofficial release of GCC._________________________________________________________________InstallationProblems building the Fortran compilerThe Fortran front end can not be built with most vendor compilers; itmust be built with gcc. As a result, you may get an error if you donot follow the install instructions carefully.In particular, instead of using "make" to build GCC, you should use"make bootstrap" if you are building a native compiler or "make cross"if you are building a cross compiler.It has also been reported that the Fortran compiler can not be builton Red Hat 4.X GNU/Linux for the Alpha. Fixing this may requireupgrading binutils or to Red Hat 5.0; we'll provide more informationas it becomes available._________________________________________________________________How to install multiple versions of gccIt may be desirable to install multiple versions of the compiler onthe same system. This can be done by using different prefix paths atconfigure time and a few symlinks.Basically, configure the two compilers with different --prefixoptions, then build and install each compiler. Assume you want "gcc"to be the latest compiler and available in /usr/local/bin; also assumethat you want "gcc2" to be the older gcc2 compiler and also availablein /usr/local/bin.The easiest way to do this is to configure the new GCC with--prefix=/usr/local/gcc and the older gcc2 with--prefix=/usr/local/gcc2. Build and install both compilers. Then makea symlink from /usr/local/bin/gcc to /usr/local/gcc/bin/gcc and from/usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar linksfor the "g++", "c++" and "g77" compiler drivers.An alternative to using symlinks is to configure with a--program-transform-name option. This option specifies a sed commandto process installed program names with. Using it you can, forinstance, have all the new GCC programs installed as "new-gcc" and thelike. You will still have to specify different --prefix options fornew GCC and old GCC, because it is only the executable program namesthat are transformed. The difference is that you (as administrator) donot have to set up symlinks, but must specify additional directoriesin your (as a user) PATH. A complication with --program-transform-nameis that the sed command invariably contains characters significant tothe shell, and these have to be escaped correctly, also it is notpossible to use "^" or "$" in the command. Here is the option toprefix "new-" to the new GCC installed programs"--program-transform-name='s,\\\\(.*\\\\),new-\\\\1,'". With the above--prefix option, that will install the new GCC programs into/usr/local/gcc/bin with names prefixed by "new-". You can use--program-transform-name if you have multiple versions of GCC, andwish to be sure about which version you are invoking.If you use --prefix, GCC may have difficulty locating a GNU assembleror linker on your system, [62]GCC can not find GNU as/GNU ld explainshow to deal with this._________________________________________________________________Dynamic linker is unable to find GCC librariesThis problem manifests itself by programs not finding shared librariesthey depend on when the programs are started. Note this problem oftenmanifests itself with failures in the libio/libstdc++ tests afterconfiguring with --enable-shared and building GCC.GCC does not specify a runpath so that the dynamic linker can finddynamic libraries at runtime.The short explanation is that if you always pass a -R option to thelinker, then your programs become dependent on directories which maybe NFS mounted, and programs may hang unnecessarily when an NFS servergoes down.The problem is not programs that do require the directories; thoseprograms are going to hang no matter what you do. The problem isprograms that do not require the directories.SunOS effectively always passed a -R option for every -L option; thiswas a bad idea, and so it was removed for Solaris. We should notrecreate it.However, if you feel you really need such an option to be passedautomatically to the linker, you may add it to the gcc specs file.This file can be found in the same directory that contains cc1 (rungcc -print-prog-name=cc1 to find it). You may add linker flags such as-R or -rpath, depending on platform and linker, to the *link or *libspecs.Another alterative is to install a wrapper script around gcc, g++ orld that adds the appropriate directory to the environment variableLD_RUN_PATH or equivalent (again, it's platform-dependent).Yet another option, that works on a few platforms, is to hard-code thefull pathname of the library into its soname. This can only beaccomplished by modifying the appropriate .ml file withinlibstdc++/config (and also libg++/config, if you are building libg++),so that $(libdir)/ appears just before the library name in -soname or-h options._________________________________________________________________GCC can not find GNU as/GNU ldGCC searches the PATH for an assembler and a loader, but it only doesso after searching a directory list hard-coded in the gcc executables.Since, on most platforms, the hard-coded list includes directories inwhich the system asembler and loader can be found, you may have totake one of the following actions to arrange that gcc uses the GNUversions of those programs.To ensure that GCC finds the GNU assembler (the GNU loader), which arerequired by [63]some configurations, you should configure these withthe same --prefix option as you used for GCC. Then build & install GNUas (GNU ld) and proceed with building GCC.Another alternative is to create links to GNU as and ld in any of thedirectories printed by the command `gcc -print-search-dirs | grep'^programs:''. The link to `ld' should be named `real-ld' if `ld'already exists. If such links do not exist while you're compiling GCC,you may have to create them in the build directories too, within thegcc directory _and_ in all the gcc/stage* subdirectories.GCC 2.95 allows you to specify the full pathname of the assembler andthe linker to use. The configure flags are `--with-as=/path/to/as' and`--with-ld=/path/to/ld'. GCC will try to use these pathnames beforelooking for `as' or `(real-)ld' in the standard search dirs. If, atconfigure-time, the specified programs are found to be GNU utilities,`--with-gnu-as' and `--with-gnu-ld' need not be used; these flags willbe auto-detected. One drawback of this option is that it won't allowyou to override the search path for assembler and linker withcommand-line options -B/path/ if the specified filenames exist._________________________________________________________________cpp: Usage:... ErrorIf you get an error like this when building GCC (particularly whenbuilding __mulsi3), then you likely have a problem with yourenvironment variables.cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp[switches] input outputFirst look for an explicit '.' in either LIBRARY_PATH orGCC_EXEC_PREFIX from your environment. If you do not find an explicit'.', look for an empty pathname in those variables. Note that ':' ateither the start or end of these variables is an implicit '.' and willcause problems.Also note '::' in these paths will also cause similar problems._________________________________________________________________Testsuite problemsWhy is there no testsuite in GCC 2.95The GCC testsuite is not included in the GCC 2.95 release due to theuncertain copyright status of some tests.The GCC team will be reviewing the entire testsuite to find and removeany tests with uncertain copyright status. Once those tests areremoved from the testsuite, the testsuite as a whole will becopyrighted under the terms of the GPL and included in future GCCreleases.It is believed that only a few tests have uncertain copyright statusand thus only a few tests will need to be removed from the testsuite._________________________________________________________________Unable to run the testsuiteIf you get a message about unable to find "standard.exp" when tryingto run the GCC testsuites, then your dejagnu is too old to run the GCCtests. You will need to get a newer version of dejagnu; we've made a[64]dejagnu snapshot available until a new version of dejagnu can bereleased._________________________________________________________________How do I pass flags like -fnew-abi to the testsuite?If you invoke runtest directly, you can use the --tool_opts option,e.g:runtest --tool_opts "-fnew-abi -fno-honor-std" <other options>Or, if you use make check you can use the make variable RUNTESTFLAGS,e.g:make RUNTESTFLAGS='--tool_opts "-fnew-abi -fno-honor-std"' check-g++_________________________________________________________________How can I run the test suite with multiple options?If you invoke runtest directly, you can use the --target_board option,e.g:runtest --target_board "unix{-fPIC,-fpic,}" <other options>Or, if you use make check you can use the make variable RUNTESTFLAGS,e.g:make RUNTESTFLAGS='--target_board "unix{-fPIC,-fpic,}"' check-gccEither of these examples will run the tests three times. Once with-fPIC, once with -fpic, and once with no additional flags.This technique is particularly useful on multilibbed targets._________________________________________________________________Platform-specific issuesPlease read the [65]host/target specific installation notes, too.Problems with exception handling on x86 platformsIf you are using the GNU assembler (aka gas) on an x86 platform andexception handling is not working correctly, then odds are you'reusing a buggy assembler. Releases of binutils prior to 2.9 are knownto assemble exception handling code incorrectly.We recommend binutils-2.9.1 or newer. Some post-2.9.1 snapshots ofbinutils fix some subtle bugs, particularly on x86 and alpha. They areavailable at [66]ftp://tsx-11.mit.edu/pub/linux/packages/GCC/. The2.9.1.0.15 snapshot is known to work fine on those platforms; otherthan that, be aware that snapshots are in general untested and may notwork (or even build). Use them at your own risk._________________________________________________________________Problems with invalid `asm' statementsPrevious releases of GCC (for example, GCC 2.7.2 or EGCS 1.1.2) didnot detect as invalid a clobber specifier that clobbered an operand.Instead, it could spuriously and silently generate incorrect code forcertain non-obvious cases of source code. Even more unfortunately, themanual (Using and Porting GCC, section Extended Asm, see the [67]bugreport entry) did not explicitly say that it was invalid to specifyclobber registers that were destined to overlap operands; it couldarguably be interpreted that it was correct to clobber an inputoperand to mark it as not holding a usable value after the asm.For the general case, there is no way to tell whether a specifiedclobber is _intended_ to overlap with a specific (input) operand or isa program error, where the choice of actual register for operandsfailed to _avoid_ the clobbered register. Such unavoidable overlap isdetected by versions GCC 2.95 and newer, and flagged as an errorrather than accepted. An error message is given, such as:foo.c: In function `foo':foo.c:7: Invalid `asm' statement:foo.c:7: fixed or forbidden register 0 (ax) was spilled for class AREG.Unfortunately, a lot of existing software, for example the [68]Linuxkernel version 2.0.35 for the Intel x86, has constructs where inputoperands are marked as clobbered.The manual now describes how to write constructs with operands thatare modified by the construct, but not actually used. To write an asmwhich modifies an input operand but does not output anything usable,specify that operand as an _output operand_ outputting to an _unuseddummy variable_.In the following example for the x86 architecture (taken from theLinux 2.0.35 kernel -- include/asm-i386/delay.h), the register-classconstraint "a" denotes a register class containing the single register"ax" (aka. "eax"). It is therefore invalid to clobber "ax"; thisoperand has to be specified as an output as well as an input. Thefollowing code is therefore _invalid_:extern __inline__ void__delay (int loops){__asm__ __volatile__(".align 2,0x90\n1:\tdecl %0\n\tjns 1b": /* no outputs */: "a" (loops): "ax");}It could be argued that since the register class for "a" contains onlya single register, this could be detected as an "obvious" intendedclobber of the input operand. While that is feasible, it opens up forfurther "obvious" cases, where the level of obviousness changes fromperson to person. As there is a correct way to write such asmconstructs, this obviousness-detection is not needed other than forreasons of compatibility with an existing code-base, and that codebase can be corrected.This corrected and clobber-less version, is _valid_ for GCC 2.95 aswell as for previous versions of GCC and EGCS:extern __inline__ void__delay (int loops){int dummy;__asm__ __volatile__(".align 2,0x90\n1:\tdecl %0\n\tjns 1b": "=a" (dummy): "0" (loops));}Note that the asm construct now has an output operand, but it isunused. Normally asm constructs with only unused output operands maybe removed by gcc, unless marked volatile as above._________________________________________________________________Building Linux kernelsThe linux kernel violates certain aliasing rules specified in theANSI/ISO standard. Starting with GCC 2.95, the gcc optimizer bydefault relies on these rules to produce more efficient code and thuswill produce malfunctioning kernels. To work around this problem, theflag -fno-strict-aliasing must be added to the CFLAGS variable in themain kernel Makefile.If you try to build a 2.0.x kernel for Intel machines with anycompiler other than GCC 2.7.2, then you are on your own. The 2.0.xkernels are to be built only with gcc 2.7.2. They use certain asmconstructs which are incorrect, but (by accident) happen to work withgcc 2.7.2. If you insist on building 2.0.x kernels with egcs, you maybe interested in this [69]patch which fixes some of the asm problems.You will also want to change asm constructs to [70]avoid clobberingtheir input operands.If you installed a recent binutils/gas snapshot on your GNU/Linuxsystem, you may not be able to build the kernel because objdump doesnot understand the "-k" switch. The solution for this problem is toremove /usr/bin/encaps. (This is an obsolete program that was part ofolder binutils distributions; the Linux kernel's Makefile looks forthis program to decide if you have an old or a new binutils. Problemsoccur if you installed a new binutils but haven't removed encaps,because the Makefile thinks you have the old one.)Finally, you may get errors with the X driver of the form_X11TransSocketUNIXConnect: Can't connect: errno = 111This is a kernel bug. The function sys_iopl inarch/i386/kernel/ioport.c does an illegal hack which used to work butis now broken since GCC optimizes more aggressively . The newer 2.1.xkernels already have a fix which should also work in 2.0.32._________________________________________________________________How do I compile X11 headers with g++When compiling X11 headers with a GCC 2.95 or newer, g++ will complainthat types are missing. These headers assume that omitting the typemeans 'int'; this assumption is wrong for C++.g++ accepts such (illegal) constructs with the option -fpermissive; itwill assume that missing type is 'int' (as defined by the C89standard).Since the upcoming C99 standard also obsoletes the implicit typeassumptions, the X11 headers have to get fixed eventually._________________________________________________________________How to build a cross compilerBuilding cross compilers is a rather complex undertaking because theyusually need additional software (cross assembler, cross linker,target libraries, target include files, etc).We recommend reading the [71]crossgcc FAQ for information aboutbuilding cross compilers.If you have all the pieces available, then `make cross' should build across compiler. `make LANGUAGES="c c++" install' will install thecross compiler.Note that if you're trying to build a cross compiler in a tree whichincludes binutils-2.8 in addition to GCC, then you're going to need tomake a couple minor tweaks so that the cross assembler, linker and nmutilities will be found.binutils-2.8 builds those files as gas.new, ld.new and nm.new; GCClooks for them using gas-new, ld-new and nm-new, so you may have toarrange for any symlinks which point to <file>.new to be changed to<file>-new._________________________________________________________________Bugs and Non-BugsUnfortunately, improvements in tools that are widely used are sooneror later bound to break _something_. Sometimes, the code that breakswas wrong, and then that code should be fixed, even if it works forearlier versions of gcc or other compilers. The following problemswith some releases of widely used packages have been identified:There is a separate [72]list of well-known bugs describing knowndeficiencies. Naturally we'd like that list to be of zero length.To report a bug, see [73]How to report bugs._________________________________________________________________FD_ZERO macroThe FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect. It uses[74]invalid asm clobbers. The following rewrite by Ulrich Drepper<drepper@cygnus.com> should fix this for glibc 2.0:# define __FD_ZERO(fdsetp) \do { \int __d0, __d1; \__asm__ __volatile__ ("cld; rep; stosl" \: "=m" (((__fd_mask *) \(fdsetp))[__FDELT (__FD_SETSIZE)]), \"=&c" (__d0), "=&D" (__d1) \: "a" (0), "1" (sizeof (__fd_set) \/ sizeof (__fd_mask)), \"2" ((__fd_mask *) (fdsetp)) \: "memory"); \} while (0)_________________________________________________________________Octave 2.0.13 does not compileApparently Octave 2.0.13 uses some C++ features which have beenobsoleted and thus fails to build with EGCS 1.1 and later. This[75]patch to Octave should fix this.Octave 2.0.13.96, a test release, has been compiled without patches byegcs 1.1.2. It is available at[76]ftp://ftp.che.wisc.edu/pub/octave/test-releases/._________________________________________________________________Why can't I initialize a static variable with stdin?This has nothing to do with gcc, but people ask us about it a lot.Code like this:#include <stdio.h>FILE *yyin = stdin;will not compile with GNU libc (Linux libc6), because stdin is not aconstant. This was done deliberately, in order for there to be nolimit on the number of open FILE objects. It is surprising for peopleused to traditional Unix C libraries, but it is permitted by the Cstandard.This construct commonly occurs in code generated by old versions oflex or yacc. We suggest you try regenerating the parser with a currentversion of flex or bison, respectively. In your own code, theappropriate fix is to move the initialization to the beginning ofmain.There is a common misconception that the GCC developers areresponsible for GNU libc. These are in fact two entirely separateprojects. The appropriate place to ask questions relating to GNU libcis [77]libc-alpha@sourceware.cygnus.com._________________________________________________________________Why can't I use #if here?Let me guess... you wrote code that looks something like this:memcpy(dest, src,#ifdef PLATFORM112#else24#endif);and you got a whole pile of error messages:test.c:11: warning: preprocessing directive not recognized within macro argtest.c:11: warning: preprocessing directive not recognized within macro argtest.c:11: warning: preprocessing directive not recognized within macro argtest.c: In function `foo':test.c:6: undefined or invalid # directivetest.c:8: undefined or invalid # directivetest.c:9: parse error before `24'test.c:10: undefined or invalid # directivetest.c:11: parse error before `#'The problem, simply put, is that GCC's preprocessor does not allow youto put #ifdef (or any other directive) inside the arguments of amacro. Your C library's string.h happens to define memcpy as a macro -this is perfectly legitimate. The code therefore will not compile.We have two good reasons for not allowing directives inside macroarguments. First, it is not portable. It is "undefined behavior"according to the C standard; that means different compilers will dodifferent things with it. Some will give you errors. Some will dumpcore. Some will silently mangle your code - you could get theequivalent ofmemcpy(dest, src, 1224);from the above example. A very few might do what you expected it to.We therefore feel it is most useful for GCC to reject this constructimmediately so that it is found and fixed.Second, it is extraordinarily difficult to implement the preprocessorsuch that it does what you would expect for every possible directivefound inside a macro argument. The best example is perhaps#define foo(arg) ... arg ...foo(blah#undef fooblah)which is impossible to implement in portable C without leaking memory.Allowing only a subset of directives would be confusing.It is always possible to rewrite code which uses conditionals insidemacros so that it doesn't. You could write the above example#ifdef PLATFORM1memcpy(dest, src, 12);#elsememcpy(dest, src, 24);#endifThis is a bit more typing, but I personally think it's better style inaddition to being more portable._________________________________________________________________MiscellaneousVirtual memory exhausted errorThis error means your system ran out of memory; this can happen forlarge files, particularly when optimizing. If you're getting thiserror you should consider trying to simplify your files or reducingthe optimization level.Note that using -pedantic or -Wreturn-type can cause an explosion inthe amount of memory needed for template-heavy C++ code, such as codethat uses STL. Also note that -Wall includes -Wreturn-type, so if youuse -Wall you will need to specify -Wno-return-type to turn it off._________________________________________________________________Snapshots, how, when, whyWe make snapshots of the GCC sources about once a week; there is nopredetermined schedule. These snapshots are intended to give everyoneaccess to work in progress. Any given snapshot may generate incorrectcode or even fail to build.If you plan on downloading and using snapshots, we highly recommendyou subscribe to the GCC mailing lists. See [78]mailing lists on themain GCC page for instructions on how to subscribe.When using the diff files to update from older snapshots to newersnapshots, make sure to use "-E" and "-p" arguments to patch so thatempty files are deleted and full pathnames are provided to patch. Ifyour version of patch does not support "-E", you'll need to get anewer version. Also note that you may need autoconf, autoheader andvarious other programs if you use diff files to update from onesnapshot to the next._________________________________________________________________Friend TemplatesIn order to make a specialization of a template function a friend of a(possibly template) class, you must explicitly state that the friendfunction is a template, by appending angle brackets to its name, andthis template function must have been declared already. Here's anexample:template <typename T> class foo {friend void bar(foo<T>);}The above declaration declares a non-template function named bar, soit must be explicitly defined for _each_ specialization of foo. Atemplate definition of bar won't do, because it is unrelated with thenon-template declaration above. So you'd have to end up writing:void bar(foo<int>) { /* ... */ }void bar(foo<void>) { /* ... */ }If you meant bar to be a template function, you should haveforward-declared it as follows. Note that, since the template functiondeclaration refers to the template class, the template class must beforward-declared too:template <typename T>class foo;template <typename T>void bar(foo<T>);template <typename T>class foo {friend void bar<>(foo<T>);};template <typename T>void bar(foo<T>) { /* ... */ }In this case, the template argument list could be left empty, becauseit can be implicitly deduced from the function arguments, but theangle brackets must be present, otherwise the declaration will betaken as a non-template function. Furthermore, in some cases, you mayhave to explicitly specify the template arguments, to removeambiguity.An error in the last public comment draft of the ANSI/ISO C++ Standardand the fact that previous releases of gcc would accept such frienddeclarations as template declarations has led people to believe thatthe forward declaration was not necessary, but, according to the finalversion of the Standard, it is._________________________________________________________________Where to find libg++Many folks have been asking where to find libg++ for GCC. First weshould point out that few programs actually need libg++; most onlyneed libstdc++/libio which are included in the GCC distribution.If you do need libg++ you can get a libg++ release that works with GCCfrom [79]ftp://egcs.cygnus.com/pub/egcs/infrastructure/. Note that the2.8.2 snapshot pre-dates the 2.8.1.2 release._________________________________________________________________autoconf, bison, xgettext, automake, etcIf you're using diffs up dated from one snapshot to the next, or ifyou're using the CVS repository, you may need several additionalprograms to build GCC.These include, but are not necessarily limited to autoconf, automake,bison, and xgettext.This is necessary because neither diff nor cvs keep timestampscorrect. This causes problems for generated files as "make" may thinkthose generated files are out of date and try to regenerate them.An easy way to work around this problem is to use the gcc_updatescript in the contrib subdirectory of GCC, which handles thistransparently without requiring installation of any additional tools.(Note: Up to and including GCC 2.95 this script was called egcs_update.)When building from diffs or CVS or if you modified some sources, youmay also need to obtain development versions of some GNU tools, as theproduction versions do not necessarily handle all features needed torebuild GCC.Autoconf is available from [80]http://sourceware.cygnus.com/autoconf/;have a look at [81]ftp://egcs.cygnus.com/pub/egcs/infrastructure/ forthe other packages._________________________________________________________________Conflicts when using cvs updateIt is not uncommon to get CVS conflict messages for some generatedfiles when updating your local sources from the CVS repository.Typically such conflicts occur with bison or autoconf generated files.As long as you haven't been making modifications to the generatedfiles or the generator files, it is safe to delete the offending file,then run cvs update again to get a new copy._________________________________________________________________Problems debugging GCC codeOn some systems GCC will produce dwarf debug records by default;however the gdb-4.16 release may not be able to read such debugrecords.You can either use the argument "-gstabs" instead of "-g" or pick up acopy of gdb-4.17 to work around the problem._________________________________________________________________Using GCC with GNAT/AdaThe GNU Ada front-end is not currently supported by GCC; however, itis possible to build the GNAT compiler with a little work.First, retrieve the gnat-3.10p sources. The sources for the Ada frontend and runtime all live in the "ada" subdirectory. Move thatsubdirectory to egcs/gcc/ada.Second, apply the patch found in egcs/gcc/README.gnat.Finally, rebuild per the GNAT build instructions._________________________________________________________________Using GCC with GNU PascalThe [82]GNU Pascal front-end does work with EGCS 1.1 It does not workwith EGCS 1.0.x and the main branch of the CVS repository. A tarballcan be found at[83]ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/._________________________________________________________________Using CVS to download snapshotsIt is possible to checkout specific snapshots with CVS or to check outthe latest snapshot.We use CVS tags to identify each snapshot we make. Snapshot tags havethe form "egcs_ss_YYYYMMDD". In addition, the latest official snapshotalways has the tag "gcc_latest_snapshot"._________________________________________________________________Why can't I build a shared library?When building a shared library you may get an error message from thelinker like `assert pure-text failed:' or `DP relative code in file'.This kind of error occurs when you've failed to provide proper flagsto gcc when linking the shared library.You can get this error even if all the .o files for the shared librarywere compiled with the proper PIC option. When building a sharedlibrary, gcc will compile additional code to be included in thelibrary. That additional code must also be compiled with the properPIC option.Adding the proper PIC option (-fpic or -fPIC) to the link line whichcreates the shared library will fix this problem on targets thatsupport PIC in this manner. For example:gcc -c -fPIC myfile.cgcc -shared -o libmyfile.so -fPIC myfile.o_________________________________________________________________How to work around too long C++ symbol names? (-fsquangle)If the standard assembler of your platform can't cope with the largesymbol names that the default g++ name mangling mechanism produces,your best bet is to use GNU as, from the GNU binutils package.Unfortunately, GNU as does not support all platforms supported byegcs, so you may have to use an experimental work-around: the-fsquangle option, that enables compression of symbol names.Note that this option is still under development, and subject tochange. Since it modifies the name mangling mechanism, you'll need tobuild libstdc++ and any other C++ libraries with this option enabled.Furthermore, if this option changes its behavior in the future, you'llhave to rebuild them all again. :-(This option can be enabled by default by initializing`flag_do_squangling' with `1' in `gcc/cp/decl2.c' (it is notinitialized by default), then rebuilding egcs and any C++ libraries._________________________________________________________________When building from CVS sources, I see 'gperf: invalid option -- F', even withthe most current version of gperf.The current version of gperf (v2.7) does not support the -F flag whichis used when building egcs from CVS sources. You will need to obtain apatch for gperf and rebuild the program; this patch is available at[84]ftp://egcs.cygnus.com/pub/egcs/infrastructure/Patches for other tools, particularly autoconf, may also be necessaryif you're building from CVS sources. Please see the [85]FAQ entryregarding these tools to determine if anything else is needed.These patched utilities should _only_ be required if you are buildingfrom CVS sources. For example, gperf is used to generate C code for aperfect hash function given an input file. Distributions of egcsalready contain the generated C code, while the CVS sources willprovide only the gperf input file. So gperf should only be necessaryif you are building anything obtained from CVS._________________________________________________________________When building C++, the linker says my constructors, destructors or virtualtables are undefined, but I defined themThe ISO C++ Standard specifies that all virtual methods of a classthat are not pure-virtual must be defined, but does not require anydiagnostic for violations of this rule [class.virtual]/8. Based onthis assumption, egcs will only emit the implicitly definedconstructors, the assignment operator, the destructor and the virtualtable of a class in the translation unit that defines its first suchnon-inline method.Therefore, if you fail to define this particular method, the linkermay complain about the lack of definitions for apparently unrelatedsymbols. Unfortunately, in order to improve this error message, itmight be necessary to change the linker, and this can't always bedone.The solution is to ensure that all virtual methods that are not pureare defined. Note that a destructor must be defined even if it isdeclared pure-virtual [class.dtor]/7._________________________________________________________________What is libstdc++-v3 and how can I use it with g++?From the [86]libstdc++-FAQ: "The EGCS Standard C++ Library v3, orlibstdc++-2.90.x, is an ongoing project to implement the ISO 14882Standard C++ library as described in chapters 17 through 27 and annexD."At the moment the libstdc++-v3 is no "drop in replacement" for GCC'slibstdc++. The best way to use it is as follows:1. Build and install GCC2. Build and install libstdc++-v33. Use compiler flags to use the new libstdc++Please note that the libstdc++-v3 is not yet complete and should onlybe used by experienced programmers.For more information please refer to the [87]libstdc++-v3 homepage_________________________________________________________________[88]Return to the GCC home page_Last modified: October 19, 1999_References1. http://www.gnu.org/software/gcc/faq.html2. http://www.eskimo.com/~scs/C-faq/top.html3. http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/4. http://reality.sgi.com/austern_mti/std-c++/faq.html5. http://www.fortran.com/fortran/info.html6. http://gcc.gnu.org/faq.html#general7. http://gcc.gnu.org/faq.html#gcc8. http://gcc.gnu.org/faq.html#cygnus9. http://gcc.gnu.org/faq.html#open-development10. http://gcc.gnu.org/faq.html#bugreport11. http://gcc.gnu.org/faq.html#support12. http://gcc.gnu.org/faq.html#installation13. http://gcc.gnu.org/faq.html#fortran14. http://gcc.gnu.org/faq.html#multiple15. http://gcc.gnu.org/faq.html#rpath16. http://gcc.gnu.org/faq.html#rpath17. http://gcc.gnu.org/faq.html#gas18. http://gcc.gnu.org/faq.html#environ19. http://gcc.gnu.org/faq.html#testsuite20. http://gcc.gnu.org/faq.html#testsuite21. http://gcc.gnu.org/faq.html#dejagnu22. http://gcc.gnu.org/faq.html#testoptions23. http://gcc.gnu.org/faq.html#multipletests24. http://gcc.gnu.org/faq.html#platform25. http://gcc.gnu.org/faq.html#x86eh26. http://gcc.gnu.org/faq.html#asmclobber27. http://gcc.gnu.org/faq.html#linuxkernel28. http://gcc.gnu.org/faq.html#X11R629. http://gcc.gnu.org/faq.html#cross30. http://gcc.gnu.org/faq.html#bugs31. http://gcc.gnu.org/faq.html#fdzero32. http://gcc.gnu.org/faq.html#octave33. http://gcc.gnu.org/faq.html#stdin34. http://gcc.gnu.org/faq.html#macarg35. http://gcc.gnu.org/faq.html#misc36. http://gcc.gnu.org/faq.html#memexhausted37. http://gcc.gnu.org/faq.html#snapshot38. http://gcc.gnu.org/faq.html#friend39. http://gcc.gnu.org/faq.html#libg++40. http://gcc.gnu.org/faq.html#generated_files41. http://gcc.gnu.org/faq.html#gdb42. http://gcc.gnu.org/faq.html#conflicts43. http://gcc.gnu.org/faq.html#gnat44. http://gcc.gnu.org/faq.html#gpc45. http://gcc.gnu.org/faq.html#cvssnapshots46. http://gcc.gnu.org/faq.html#picflag-needed47. http://gcc.gnu.org/spam.html48. http://gcc.gnu.org/faq.html#squangle49. http://gcc.gnu.org/faq.html#gperf50. http://gcc.gnu.org/faq.html#vtables51. http://gcc.gnu.org/faq.html#libstdc++52. http://gcc.gnu.org/steering.html53. http://gcc.gnu.org/steering.html54. http://gcc.gnu.org/faq.html#cathedral-vs-bazaar55. http://locke.ccil.org/~esr/writings/cathedral.html56. http://gcc.gnu.org/onlinedocs/57. http://egcs.cygnus.com/cgi-bin/cvsweb.cgi/~checkout~/egcs/gcc/BUGS?content-type=text/plain&only_with_tag=HEAD58. http://gcc.gnu.org/bugs.html59. mailto:gcc-bugs@gcc.gnu.org60. mailto:bug-gcc@gnu.org61. http://gcc.gnu.org/faq.html#bugreport62. http://gcc.gnu.org/faq.html#gas63. http://gcc.gnu.org/install/specific.html64. ftp://egcs.cygnus.com/pub/egcs/infrastructure/dejagnu-19981026.tar.gz65. http://gcc.gnu.org/install/specific.html66. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/67. http://gcc.gnu.org/faq.html#bugreport68. http://gcc.gnu.org/faq.html#linuxkernel69. http://www.suse.de/~florian/kernel+egcs.html70. http://gcc.gnu.org/faq.html#asmclobber71. http://www.objsw.com/CrossGCC/72. http://gcc.gnu.org/bugs.html73. http://gcc.gnu.org/faq.html#bugreport74. http://gcc.gnu.org/faq.html#asmclobber75. http://www.che.wisc.edu/octave/mailing-lists/bug-octave/1998/27076. ftp://ftp.che.wisc.edu/pub/octave/test-releases/77. mailto:libc-alpha@sourceware.cygnus.com78. http://gcc.gnu.org/index.html#mailinglists79. ftp://egcs.cygnus.com/pub/egcs/infrastructure/80. http://sourceware.cygnus.com/autoconf/81. ftp://egcs.cygnus.com/pub/egcs/infrastructure/82. http://home.pages.de/~GNU-Pascal/83. ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/84. ftp://egcs.cygnus.com/pub/egcs/infrastructure85. http://gcc.gnu.org/faq.html#generated_files86. http://sourceware.cygnus.com/libstdc++/faq/87. http://sourceware.cygnus.com/libstdc++/88. http://gcc.gnu.org/index.html