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