gcc-4.1.2/faq.html

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