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