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