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