source: trunk/third/gcc/faq.html @ 18474

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