home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / g++-FAQ / plain next >
Encoding:
Internet Message Format  |  1998-09-03  |  81.1 KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.tamu.edu!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!199.0.154.208!news2.ais.net!jamie!ais.net!uunet!uunet!uunet!in1.uu.net!aesop.synopsys.com!news.synopsys.com!jbuck
  2. From: jbuck@synopsys.com (Joe Buck)
  3. Newsgroups: gnu.g++.help,comp.lang.c++,news.answers,comp.answers
  4. Subject: FAQ for g++ and libg++, plain text version  [Revised 15 Jun 1998]
  5. Supersedes: <g++-FAQ_08_15_1998_texi@synopsys.com>
  6. Followup-To: poster
  7. Date: 1 Sep 1998 13:00:33 GMT
  8. Organization: Synopsys, Inc.
  9. Lines: 1905
  10. Approved: news-answers-request@MIT.edu
  11. Expires: 1 Oct 1998 00:00:00 GMT
  12. Message-ID: <g++-FAQ_09_01_1998_texi@synopsys.com>
  13. NNTP-Posting-Host: atrus.synopsys.com
  14. Originator: jbuck@atrus
  15. Xref: senator-bedfellow.mit.edu gnu.g++.help:20921 comp.lang.c++:340527 news.answers:138982 comp.answers:32865
  16.  
  17. Archive-name: g++-FAQ/plain
  18. Last-modified: 15 Jun 1998
  19. Frequency: bimonthly
  20.  
  21. [ this is the plain text version, the parent is the texinfo version ]
  22.  
  23.  
  24. FAQ for g++ and libg++, by Joe Buck (jbuck@synopsys.com)
  25. ********************************************************
  26.  
  27.    This is a list of frequently asked questions (FAQ) for g++ users;
  28. thanks to all those who sent suggestions for improvements.  Thanks to
  29. Marcus Speh for doing the index.  A hypertext version is available on
  30. the World Wide Web at `http://www.cygnus.com/misc/g++FAQ_toc.html'.
  31.  
  32.    Please send updates and corrections to the FAQ to
  33. `jbuck@synopsys.com'.  Please do *not* use me as a resource to get your
  34. questions answered; that's what `gnu.g++.help' is for and I don't have
  35. the time to support the net's use of g++.  If you ignore this request
  36. your message to me may be deleted without a reply.  Sorry.
  37.  
  38.    Many FAQs, including this one, are available on the archive site
  39. "rtfm.mit.edu"; see
  40. `ftp://rtfm.mit.edu/pub/usenet/news.answers'.  This FAQ may be found in
  41. the subdirectory g++-FAQ.
  42.  
  43.    This FAQ is intended to supplement, not replace, Marshall Cline's
  44. excellent FAQ for the C++ language and for the newsgroup
  45. `comp.lang.c++'.  Especially if g++ is the first C++ compiler you've
  46. ever used, the question "How do I do <X> with g++?" is probably really
  47. "How do I do <X> in C++?".  You can find this FAQ at
  48. `ftp://rtfm.mit.edu/pub/usenet/comp.lang.c++', or in HTML form at
  49. `http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/'.
  50.  
  51. The basics: what is g++?
  52. ************************
  53.  
  54.    g++ is the traditional nickname of GNU C++, a freely redistributable
  55. C++ compiler produced by the Free Software Foundation plus dozens of
  56. skilled volunteers.  I say "traditional nickname" because the GNU
  57. compiler suite, gcc, bundles together compilers for C, Objective-C, and
  58. C++ in one package.
  59.  
  60.    While the source code to gcc/g++ can be downloaded for free, it is
  61. not public domain, but is protected by the GNU Public License, or GPL
  62. (*note legalities::.).
  63.  
  64. What is the latest version of gcc, g++, and libg++?
  65. ===================================================
  66.  
  67.    The newest release from the egcs project (on the Web:
  68. `http://www.cygnus.com/egcs/') is egcs-1.0.3, released May 15, 1998.
  69.  
  70.    The current version of gcc/g++ is 2.8.1, released March 4, 1998.
  71. This release fixes some bugs in the 2.8.x release from January.  It is
  72. a huge improvement over the 2.7.x releases.
  73.  
  74.    libg++ has now been deprecated (that is, it is no longer really
  75. supported), so gcc2.8.1 users need to grab libstdc++-2.8.1 from their
  76. favorite GNU site (egcs users don't need to get this separately as it
  77. is bundled with egcs).  However, there is an 'add-on' libg++ 2.8.1
  78. mini-release.  If you want to use it, you need to combine it with
  79. libstdc++ 2.8.1.
  80.  
  81.    I would strongly recommend that anyone using a g++ version earlier
  82. than 2.7.2 should upgrade if at all possible (*note version 2.7.x::.).
  83. Folks who need modern C++ features should upgrade to 2.8.1 or egcs.
  84.  
  85.    For some non-Unix platforms, the latest port of gcc may be an earlier
  86. version (2.7.2, say).  You'll need to use a version of libg++ that has
  87. the same first two digits as the compiler version, e.g. use libg++
  88. 2.7.x (for the latest x you can find) with gcc version 2.7.2.1.
  89.  
  90.    From version 2.8.0 on, you don't need libg++, you only need libstdc++
  91. (again, the latest version with the same two leading digits as the
  92. version of g++ you use).
  93.  
  94.    The latest "1.x" version of gcc is 1.42, and the latest "1.x"
  95. version of g++ is 1.42.0.  While gcc 1.42 is quite usable for C
  96. programs, g++ 1.x is only of historical interest (since the C++
  97. language has changed so much).
  98.  
  99. How do I get a copy of g++ for Unix?
  100. ====================================
  101.  
  102.    First, you may already have it if you have gcc for your platform;
  103. g++ and gcc are combined now (as of gcc version 2.0).
  104.  
  105.    You can get g++ from a friend who has a copy, by anonymous FTP or
  106. UUCP, or by ordering a tape or CD-ROM from the Free Software Foundation.
  107.  
  108.    The Free Software Foundation is a nonprofit organization that
  109. distributes software and manuals to raise funds for more GNU
  110. development.  Getting your copy from the FSF contributes directly to
  111. paying staff to develop GNU software.  CD-ROMs cost $400 if an
  112. organization is buying, or $100 if an individual is buying.  Tapes cost
  113. around $200 depending on media type.  I recommend asking for version 2,
  114. not version 1, of g++.
  115.  
  116.    For more information about ordering from the FSF, contact
  117. gnu@prep.ai.mit.edu, phone (617) 542-5942 or anonymous ftp file
  118. `ftp://prep.ai.mit.edu/pub/gnu/GNUinfo/ORDERS' (you can also use one of
  119. the sites listed below if you can't get into "prep").
  120.  
  121.    Here is a list of anonymous FTP archive sites for GNU software.  If
  122. no directory is given, look in `/pub/gnu'.
  123.  
  124.      ASIA: ftp.cs.titech.ac.jp, tron.um.u-tokyo.ac.jp:/pub/GNU/prep
  125.      cair-archive.kaist.ac.kr, ftp.nectec.or.th:/pub/mirrors/gnu
  126.      
  127.      AUSTRALIA: archie.au:/gnu (archie.oz or archie.oz.au for ACSnet)
  128.      
  129.      AFRICA: ftp.sun.ac.za
  130.      
  131.      MIDDLE-EAST: ftp.technion.ac.il:/pub/unsupported/gnu
  132.      
  133.      EUROPE: irisa.irisa.fr, ftp.univ-lyon1.fr,
  134.      ftp.mcc.ac.uk, unix.hensa.ac.uk:/mirrors/uunet/systems/gnu,
  135.      src.doc.ic.ac.uk:/gnu, ftp.ieunet.ie, ftp.eunet.ch,
  136.      nic.switch.ch:/mirror/gnu, ftp.informatik.rwth-aachen.de,
  137.      ftp.informatik.tu-muenchen.de, ftp.win.tue.nl, ftp.nl.net,
  138.      ftp.etsimo.uniovi.es, ftp.funet.fi, ftp.denet.dk,
  139.      ftp.stacken.kth.se, isy.liu.se, ftp.luth.se:/pub/unix/gnu,
  140.      ftp.sunet.se, archive.eu.net
  141.      
  142.      SOUTH AMERICA: ftp.inf.utfsm.cl, ftp.unicamp.br
  143.      
  144.      WESTERN CANADA: ftp.cs.ubc.ca:/mirror2/gnu
  145.      
  146.      USA: wuarchive.wustl.edu:/systems/gnu, labrea.stanford.edu,
  147.      ftp.digex.net, ftp.kpc.com:/pub/mirror/gnu, f.ms.uky.edu:/pub3/gnu,
  148.      jaguar.utah.edu:/gnustuff, ftp.hawaii.edu:/mirrors/gnu,
  149.      uiarchive.cso.uiuc.edu, ftp.cs.columbia.edu:/archives/gnu/prep,
  150.      gatekeeper.dec.com:/pub/GNU, ftp.uu.net:/systems/gnu
  151.  
  152.    The "official site" is prep.ai.mit.edu, but your transfer will
  153. probably go faster if you use one of the above machines.
  154.  
  155.    Most GNU utilities are compressed with "gzip", the GNU compression
  156. utility.  All GNU archive sites should have a copy of this program,
  157. which you will need to uncompress the distributions.
  158.  
  159.    Don't forget to retrieve libstdc++ as well!
  160.  
  161. How do I get egcs?
  162. ==================
  163.  
  164.    See *Note egcs-intro:: to find out what egcs is.
  165.  
  166.    You can obtain egcs either by FTP or with a Web browser.  To do the
  167. latter, start from `http://egcs.cygnus.com/'.  The master FTP site is
  168. `ftp://ftp.cygnus.com/pub/egcs/releases', however you'll probably get a
  169. faster download if you use a mirror site.  Mirror sites also have egcs
  170. snapshots unless otherwise noted.
  171.    * US (west coast): `ftp://go.cygnus.com/pub/ftp.cygnus.com/egcs/'
  172.  
  173.    * US (east coast): `ftp://ftp.goof.com/pub/pcg/egcs/' or (for
  174.      releases only): `ftp://cambridge.cygnus.com/pub/egcs/'
  175.  
  176.    * US (Arizona): `ftp://ftp.ninemoons.com/pub/mirrors/egcs/'
  177.  
  178.    * UK: `ftp://sunsite.doc.ic.ac.uk/Mirrors/egcs.cygnus.com/pub/egcs/'
  179.  
  180.    * Austria: `ftp://gd.tuwien.ac.at/gnu/egcs'
  181.  
  182.    * France: `ftp://ftp.ilog.fr/pub/mirrors/egcs/' or
  183.      `ftp://ftp.lip6.fr/pub/egcs'
  184.  
  185.    * Czech Republic: `ftp://sunsite.mff.cuni.cz/pub/GNU/egcs/'
  186.  
  187.    * Denmark: `ftp://sunsite.auc.dk/pub/egcs/'
  188.  
  189.    * Germany `ftp://ftp.fu-berlin.de/unix/languages/egcs/' or
  190.      `ftp://ftp.gwdg.de/pub/cygnus/egcs/'
  191.  
  192.    * Poland: `ftp://sunsite.icm.edu.pl/pub/programming/egcs/'
  193.  
  194.    * Sweden: `ftp://ftp.sunet.se/pub/gnu/egcs/'
  195.  
  196.    * Brasil (releases only, no snapshots):
  197.      `ftp://ftp.unicamp.br/pub/gnu/=EXTRA=/cygnus/egcs/'
  198.  
  199.    * Portugal: `ftp://ftp.lca.uevora.pt/pub/egcs/'
  200.  
  201.    * Romania: `ftp://ftp.lbi.ro/pub/egcs/'
  202.  
  203.    * Australia/NZ (release only): `ftp://moshpit.cygnus.com/pub/egcs/'
  204.  
  205. Getting gcc/g++ for the HP Precision Architecture
  206. =================================================
  207.  
  208.    If you use the HP Precision Architecture (HP-9000/7xx and
  209. HP-9000/8xx) and you want to use debugging, you'll need to use the GNU
  210. assembler, GAS (version 2.3 or later).  If you build from source, you
  211. must tell the configure program that you are using GAS or you won't get
  212. debugging support.  A non-standard debug format is used, since until
  213. recently HP considered their debug format a trade secret.  Thanks to
  214. the work of lots of good folks both inside and outside HP, the company
  215. has seen the error of its ways and has now released the required
  216. information.  The team at the University of Utah that did the gcc port
  217. now has code that understands the native HP format.
  218.  
  219.    There are binaries for GNU tools in `ftp://jaguar.cs.utah.edu/dist/',
  220. but these are older versions.
  221.  
  222.    Jeff Law has left the University of Utah, so the Utah prebuilt
  223. binaries may be discontinued.
  224.  
  225. Getting gcc/g++ binaries for Solaris 2.x
  226. ========================================
  227.  
  228.    "Sun took the C compiler out of Solaris 2.x.  Am I stuck?"
  229.  
  230.    You can obtain and install prebuilt binaries of gcc.
  231.  
  232.    The WWW site `http://smc.vnet.net/' contains various GNU and
  233. freeware programs for Solaris 2.5 or 2.6, for either the Sparc or Intel
  234. platforms.  These are packaged to enable easy installation using the
  235. Solaris "pkgadd" utility.  These include GNU emacs, gcc, gdb, perl, and
  236. others.
  237.  
  238.    You can find also find prebuilt binaries of many GNU tools,
  239. including the compiler, at `http://sunsite.unc.edu/pub/solaris/'.
  240.  
  241. How do I get a copy of g++ for (some other platform)?
  242. =====================================================
  243.  
  244.    As of gcc-2.7.x, there is Windows NT support in gcc.  Some special
  245. utilities are required.  See the INSTALL file from the distribution.
  246. If you're interested in GNU tools on Windows NT, see
  247. `http://www.cygnus.com/misc/gnu-win32/' on the WWW, or the anonymous
  248. FTP directory `ftp://ftp.cygnus.com/pub/gnu-win32/'.
  249.  
  250.    The standard gcc/g++ distribution includes VMS support for the Vax.
  251. Since the FSF people don't use VMS, it's likely to be somewhat less
  252. solid than the Unix version.  Precompiled copies of g++ and libg++ in
  253. VMS-installable form for the Vax are available by FTP from
  254. `ftp://mango.rsmas.miami.edu/pub/VMS-gcc/'.
  255.  
  256.    Klaus Kaempf (kkaempf@progis.de) has done a port to OpenVMS for the
  257. Alpha; this is not yet a part of the official gcc/g++.  The port
  258. includes g++ and all libraries from the libg++ distribution.  See
  259. `http://www.progis.de' for more details.
  260.  
  261.    There are two different versions of gcc/g++ for MS-DOS: EMX and
  262. DJGPP.  EMX also works for OS/2 and is described later.  DJGPP is DJ
  263. Delorie's port.  It can be found on many FTP archive sites; try
  264. `ftp://ftp.coast.net/SimTel/vendors/djgpp/' or, for a complete list, see
  265. `http://www.delorie.com/djgpp/getting.html'.
  266.  
  267.    The latest version of DJGPP is 2.00.  See
  268. `http://www.delorie.com/djgpp/v2/' for information on this version.
  269.  
  270.    FSF sells floppies with DJGPP on them; see above for ordering
  271. software from the FSF.
  272.  
  273.    DJGPP has its own newsgroup: `comp.os.msdos.djgpp'.
  274.  
  275.    Development and porting efforts for GNU tools, including gcc/g++, for
  276. the Amiga are maintained by an initiative named ADE (Amiga Developers
  277. Environment.  More information about ADE is available at
  278. `http://www.ninemoons.com/'.
  279.  
  280.    For more information on Amiga ports of gcc/g++, retrieve the file
  281. `ftp://prep.ai.mit.edu/pub/gnu/MicrosPorts/Amiga'.
  282.  
  283.    A port of gcc to the Atari ST can be found at
  284. `ftp://atari.archive.umich.edu/atari/Gnustuff/Tos' along with many
  285. other GNU programs.  This version is usually the same as the latest FSF
  286. release.  See the "Software FAQ" for the Usenet group
  287. `comp.sys.atari.st' for more information.
  288.  
  289.    EMX is a port of gcc to OS/2; it can also be used on MS-DOS.  In
  290. addition to the compiler port, the EMX port's C library attempts to
  291. provide a Unix-like environment.  For more information ask around on
  292. `comp.os.os2.programmer.porting'.  Version 0.9c, based on gcc-2.7.2.1,
  293. was released in November 1996.  It is available by FTP and the WWW
  294. from, among other places
  295.  
  296.      `http://www.os2ss.com/unix/emx09c/'
  297.      `ftp://ftp.cdrom.com/pub/os2/emx09c/' (US)
  298.      `ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/' (Germany)
  299.  
  300.    Eberhard Mattes did the EMX port.  His address is
  301. mattes@azu.informatik.uni-stuttgart.de.  Read the FAQ file included
  302. with the distribution before harrassing the author.
  303.  
  304.    I'm looking for more information on gcc/g++ support on the Apple
  305. Macintosh.  Until recently, this FAQ did not provide such information,
  306. but FSF is no longer boycotting Apple as the League for Programming
  307. Freedom boycott has been dropped.
  308.  
  309.    Versions 1.37.1 and 2.3.3 of gcc were ported by Stan Shebs and are
  310. available at
  311. `ftp://ftp.cygnus.com/pub/mac'
  312.  
  313.    They are both interfaced to MPW.  Stan is working on a version using
  314. the current (post-2.7) sources, contact him directly (shebs@cygnus.com)
  315. for more information.
  316.  
  317. But I can only find g++-1.42!
  318. =============================
  319.  
  320.    "I keep hearing people talking about g++ 2.8.1 (or some other number
  321. starting with 2), but the latest version I can find is g++ 1.42.  Where
  322. is it?"
  323.  
  324.    As of gcc 2.0, C, C++, and Objective-C as well are all combined into
  325. a single distribution called gcc.  If you get gcc you already have g++.
  326. The standard installation procedure for any gcc version 2 compiler will
  327. install the C++ compiler as well.
  328.  
  329.    One could argue that we shouldn't even refer to "g++-2.x.y" but it's
  330. a convention.  It means "the C++ compiler included with gcc-2.x.y."
  331.  
  332. The Next Generation(s) of g++
  333. *****************************
  334.  
  335. What's new in gcc/g++ 2.8.x?
  336. ============================
  337.  
  338.    After a two-year wait, gcc 2.8.0 was released in January 1998, along
  339. with libstdc++-2.8.0 and libg++-2.8.0.  This has been followed up in
  340. March by the 2.8.1 release of all three packages, though libg++-2.8.1
  341. is an "add-on" (it does not contain libstdc++ anymore).  Note that
  342. libstdc++ is required.
  343.  
  344.    For those familiar with egcs, the most obvious difference between
  345. gcc-2.8.x and egcs is the packaging: egcs is bundled with libstdc++,
  346. and gcc-2.8.x does not contain the class library.  Otherwise, except
  347. for the lack of the `-frepo' option and some bug fixes that have not
  348. yet made it into gcc-2.8.x, C++ users will find the two compilers to be
  349. almost the same at this stage, other than that 2.8.x users may get more
  350. bogus warnings with -Wall and optimization because some fixes to flow
  351. analysis in the presence of exceptions that egcs made are not yet
  352. present in gcc 2.8.x (as of 2.8.1).
  353.  
  354.    The flow analysis problem in 2.8.1 produces bad code in some cases,
  355. not just spurious errors.  It only affects code that actually throws an
  356. exception, and only the path corresponding to a thrown exception gets
  357. misoptimized.  If this happens, you can try reducing the level of
  358. optimization.
  359.  
  360.    Because the new feature lists for egcs and gcc 2.8 are almost the
  361. same, please see *Note egcs-whats-new:: for a list of new features.  It
  362. is a fairly long list.
  363.  
  364. What is egcs?
  365. =============
  366.  
  367.    egcs is the experimental GNU compiler system (see
  368. `http://www.cygnus.com/egcs' on the Web).  It is an effort to
  369. accelerate development of new gcc features by providing a more open
  370. development model than gcc has traditionally used.
  371.  
  372.    The first egcs release, egcs-1.0, came out on December 3, 1997.  The
  373. current release is egcs-1.0.3, released May 15, 1998.
  374.  
  375.    Questions not addressed here may be answered in the egcs FAQ
  376. (`http://www.cygnus.com/egcs/faq.html').
  377.  
  378. What new C++ features are in egcs?
  379. ==================================
  380.  
  381.    *Note*: unless indicated otherwise, these features are also present
  382. in g++ 2.8.x.
  383.  
  384.    * The standard C++ classes are integrated with the egcs release (but
  385.      *not* for gcc-2.8.x, which does not include the class libraries).
  386.      libg++ is not being supported, though an add-on version that will
  387.      work with egcs can be found at
  388.      `ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.0b6.6.tar.gz',
  389.      thanks to H.J. Lu.  The compiler and library are configured and
  390.      built in one step.
  391.  
  392.    * A completely new template implementation, much closer to the draft
  393.      standard.  Limitations in 2.7.2.x concerning inlining template
  394.      functions are eliminated.  Static template data members, template
  395.      class member functions, partial specification, and default
  396.      template arguments are supported.  An instantiation method
  397.      resembling that used in Borland C++ (instantiating functions
  398.      possibly in multiple .o files and using weak symbols to link
  399.      correctly) is provided, in addition to other options.  The SGI
  400.      version of STL is shipped verbatim with libstdc++ (libstdc++ is
  401.      included with egcs, separate with gcc-2.8.x).
  402.  
  403.    * On ELF platforms (Linux/ELF, Solaris, SVR4), if the GNU linker is
  404.      used, duplicated template functions and virtual function tables
  405.      are eliminated at link time.
  406.  
  407.    * The `-frepo' flag is supported in egcs (it is not in 2.8.x).
  408.      However, because of the previous item, I don't recommend its use
  409.      on ELF systems, as the default method is better.
  410.  
  411.    * Exception handling has been re-worked; exceptions will work
  412.      together with optimization.  Actually, there are two separate
  413.      implementations: one based on setjmp/longjmp and designed to be
  414.      highly portable, and one designed to be more efficient but
  415.      requiring more processor-specific support (getting exceptions
  416.      right has proven to be extremely difficult and has been the chief
  417.      obstacle to getting a new release out).
  418.  
  419.    * RTTI has been re-done to work correctly and is on by default.
  420.  
  421.    * Overloading has been re-worked to conform to the latest draft of
  422.      the standard.
  423.  
  424.    * There are many more changes: see
  425.      `http://www.cygnus.com/egcs/c++features.html' for a list.
  426.  
  427.    Features that are still missing include namespaces and templates as
  428. template arguments, though there is support for the latter feature in
  429. the egcs snapshots (which has not yet made it into a release).
  430.  
  431. What was fixed in the latest egcs releases?
  432. ===========================================
  433.  
  434.    * Add support for Red Hat 5.0 Linux and better support for Linux
  435.      systems using glibc2.  (1.0.3 was specifically done to fix some
  436.      remaining problems detected when building Red Hat 5.1).
  437.  
  438.    * Compatibility with both egcs-1.0 and gcc-2.8 libgcc exception
  439.      handling interfaces (see below).
  440.  
  441.    * Various bugfixes in the x86, hppa, mips, and rs6000/ppc backends.
  442.  
  443.    * A few machine independent bugfixes, mostly to fix code generation
  444.      bugs when building Linux kernels or glibc.
  445.  
  446.    * Fix a few critical exception handling and template bugs in the C++
  447.      compiler.
  448.  
  449.    * Fix build problems on x86-solaris systems.
  450.  
  451.    To avoid future compatibility problems, we strongly urge anyone who
  452. is planning on distributing shared libraries that contain C++ code to
  453. upgrade to at least egcs-1.0.1 first (and preferably to 1.0.3).  See
  454. `http://www.cygnus.com/egcs/egcs-1.0.1.html' for details about the
  455. compatibility issues as well as additional information about the
  456. bugfixes since the egcs-1.0 release.
  457.  
  458. If I install egcs on Linux, will it overwrite my libraries?
  459. ===========================================================
  460.  
  461.    No.  If you build from sources, by default, egcs installs
  462. executables in `/usr/local/bin' and libraries in `/usr/local/lib', and
  463. you can change this default if desired (see next section).
  464.  
  465.    If, however, you install a package (e.g. Debian or Red Hat) that
  466. wants to put egcs in `/usr/bin' and `/usr/lib', then yes, you are
  467. replacing your system compiler and C++ library (I don't know if anyone
  468. has provided such packages yet - proceed with caution).
  469.  
  470. How can I run both egcs and an FSF release of g++ on the same machine?
  471. ======================================================================
  472.  
  473.    The recommended approach is to provide a different argument to the
  474. `--prefix' flag when you configure egcs.  For example, say
  475. `--prefix=/usr/local/egcs' and then, after installation, you can make
  476. symbolic links from `/usr/local/egcs/bin' to whereever you want, for
  477. example
  478.  
  479.      ln -s /usr/local/egcs/bin/gcc /usr/local/bin/egcc
  480.      ln -s /usr/local/egcs/bin/g++ /usr/local/bin/eg++
  481.  
  482. What about 2.8.x?  How does egcs affect the 2.8.x development?
  483. ==============================================================
  484.  
  485.    2.8.0 has now been released (followed up by 2.8.1), with essentially
  486. the same C++ front end as egcs.
  487.  
  488.    Bug fixes generated in egcs will be passed to the 2.8.x releases for
  489. inclusion; the reverse is also taking place, though a bug fix may
  490. appear in one before it does in the other.  egcs development is
  491. currently proceeding much more quickly than gcc 2.8.x development.
  492. However, there is essentially only one C++ front end, which is shared
  493. by the two distinct compiler back ends (however, since egcs-1.0.3 is
  494. newer than gcc 2.8.1, it has more bug fixes).
  495.  
  496. How robust is egcs?
  497. ===================
  498.  
  499.    While the 'e' stands for 'experimental', egcs has been tested
  500. thoroughly and should be of high quality.  The author considers egcs
  501. 1.0.3 the most robust GNU C++ compiler ever produced.
  502.  
  503. Installation Issues and Problems
  504. ********************************
  505.  
  506. I can't build g++ 1.x.y with gcc-2.x.y!
  507. =======================================
  508.  
  509.    "I obtained gcc-2.x.y and g++ 1.x.y and I'm trying to build it, but
  510. I'm having major problems.  What's going on?"
  511.  
  512.    If you wish to build g++-1.42, you must obtain gcc-1.42 first.  The
  513. installation instructions for g++ version 1 leave a lot to be desired,
  514. unfortunately, and I would recommend that, unless you have a special
  515. reason for needing the 1.x compiler, that C++ users use the latest
  516. g++-2.x version, as it is the version that is being actively maintained.
  517.  
  518.    There is no template support in g++-1.x, and it is generally much
  519. further away from the ANSI draft standard than g++-2.x is.
  520.  
  521. OK, I've obtained gcc; what else do I need?
  522. ===========================================
  523.  
  524.    First off, you'll want libg++ as you can do almost nothing without it
  525. (unless you replace it with some other class library).
  526.  
  527.    Second, depending on your platform, you may need "GAS", the GNU
  528. assembler, or the GNU linker (see next question).
  529.  
  530.    Finally, while it is not required, you'll almost certainly want the
  531. GNU debugger, gdb.  The latest version is 4.17, released April 27, 1997.
  532. Other debuggers (like dbx, for example) will normally not be able to
  533. understand at least some of the debug information produced by g++.
  534.  
  535. Should I use the GNU linker, or should I use "collect"?
  536. =======================================================
  537.  
  538.    First off, for novices: special measures must be taken with C++ to
  539. arrange for the calling of constructors for global or static objects
  540. before the execution of your program, and for the calling of
  541. destructors at the end.  (Exception: System VR3 and System VR4 linkers,
  542. Linux/ELF, and some other systems support user-defined segments; g++ on
  543. these systems requires neither the GNU linker nor collect.  So if you
  544. have such a system, the answer is that you don't need either one,
  545. though using GNU ld does have some advantages over the native linker in
  546. some cases).
  547.  
  548.    If you have experience with AT&T's "cfront", this function is
  549. performed there by programs named "patch" or "munch".  With GNU C++, it
  550. is performed either by the GNU linker or by a program known as
  551. "collect".  The collect program is part of the gcc-2.x distribution;
  552. you can obtain the GNU linker separately as part of the "binutils"
  553. package.  The latest version of binutils is 2.9.1, released May 1, 1998.
  554.  
  555.    Note that if you want to use exceptions on Intel-like platforms and
  556. use gas (e.g. you run Linux), you need binutils version 2.8.1 or newer
  557. for exceptions to work correctly!
  558.  
  559.    (To be technical, it's "collect2"; there were originally several
  560. alternative versions of collect, and this is the one that survived).
  561.  
  562.    There are advantages and disadvantages to either choice.
  563.  
  564.    Advantages of the GNU linker:
  565.  
  566.    It's faster than using collect - collect basically runs the standard
  567. Unix linker on your program twice, inserting some extra code after the
  568. first pass to call the constructors.  This is a sizable time penalty
  569. for large programs.  The GNU linker does not require this extra pass.
  570.  
  571.    GNU ld reports undefined symbols using their true names, not the
  572. mangled names (but as of 2.7.0 so does collect).
  573.  
  574.    If there are undefined symbols, GNU ld reports which object file(s)
  575. refer to the undefined symbol(s).  On some OSes (e.g. SunOS, Solaris)
  576. the native linker does not do this, so you have to track down who's
  577. referring to the missing symbols yourself.
  578.  
  579.    As of binutils version 2.2, on systems that use the so-called "a.out"
  580. debug format (e.g. Suns running SunOS 4.x), the GNU linker compresses
  581. the debug symbol table considerably.  The 2.7 version adds some symbol
  582. table compression for ELF and Solaris targets.
  583.  
  584.    Users of egcs or 2.8.x on ELF systems should definitely use GNU ld
  585. (2.8 or later), as it will automatically remove duplicate
  586. instantiations of templates, virtual function tables, or "outlined"
  587. copies of inline functions.
  588.  
  589.    Advantages of collect:
  590.  
  591.    If your native linker supports shared libraries, you can use shared
  592. libraries with collect.  This used to be a strong reason *not* to use
  593. the GNU linker, but recent versions of GNU ld support linking with
  594. shared libraries on many platforms, and creating shared libraries on a
  595. few (such as Intel x86 systems that use ELF object format as well as
  596. SunOS and Solaris).
  597.  
  598.    *Note shared libraries::
  599.  
  600.    The GNU linker has not been ported to as many platforms as g++ has,
  601. so you may be forced to use collect.
  602.  
  603.    If you use collect, you don't need to get something extra and figure
  604. out how to install it; the standard gcc installation procedure will do
  605. it for you.
  606.  
  607.    I used to say at this point that I don't see a clear win for either
  608. linking alternative, but with all the improvements in the GNU linker I
  609. think that it is now the better choice.  Take your pick.
  610.  
  611.    If you run Linux, the only available linker is the GNU linker.
  612.  
  613. Should I use the GNU assembler, or my vendor's assembler?
  614. =========================================================
  615.  
  616.    This depends on your platform and your decision about the GNU
  617. linker.  For most platforms, you'll need to use GAS if you use the GNU
  618. linker.  For some platforms, you have no choice; check the gcc
  619. installation notes to see whether you must use GAS.  But you can
  620. usually use the vendor's assembler if you don't use the GNU linker.
  621.  
  622.    The GNU assembler assembles faster than many native assemblers;
  623. however, on many platforms it cannot support the local debugging format.
  624.  
  625.    It used to be that the GNU assembler couldn't handle
  626. position-independent code on SunOS.  This is no longer true if you have
  627. version 2.6 or newer.
  628.  
  629.    On HPUX or IRIX, you must use GAS (and configure gcc with the
  630. `--with-gnu-as' option) to debug your programs.  GAS is strongly
  631. recommended particularly on the HP platform because of limitations in
  632. the HP assembler.
  633.  
  634.    The GNU assembler has been merged with the binutils distribution, so
  635. the GNU assembler and linker are now together in this package (as of
  636. binutils version 2.5.1).
  637.  
  638.    On Linux the assembler is the GNU assembler.
  639.  
  640. How do I build shared libraries with g++?
  641. =========================================
  642.  
  643.    For gcc-2.7.0 and later, building C++ shared libraries should work
  644. fine on supported platforms (HPUX 9+, IRIX 5+, DEC UNIX (formerly
  645. OSF/1), SGI/IRIX, AIX, SunOS 4, Linux/ELF and all targets using
  646. SVR4-style ELF shared libraries).  There are two separate issues:
  647. building libg++ as a shared library, and making your own shared
  648. libraries.  For libg++ it is simply a matter of giving the
  649. `--enable-shared' option to the configure program.  When compiling your
  650. own code for shared libraries you generally must use the `-fPIC' flag
  651. to get position-independent code.
  652.  
  653.    If your shared library contains global or static objects with
  654. constructors, then make sure to use `gcc -shared', not `ld', to create
  655. the shared library.  This will make sure that any processor-specific
  656. magic needed to execute the constructors is included.
  657.  
  658.    In theory, constructors for objects in your shared library should be
  659. called when the library is opened (by dlopen or equivalent).  This does
  660. not work on some platforms (e.g. SunOS4; it does work on Solaris and
  661. ELF systems such as Linux): on the broken platforms, the constructors
  662. are not called correctly.
  663.  
  664.    David Nilsen has suggested the following workaround:
  665.  
  666.    The thing to realize is that if you link your dynamic module with the
  667. `-shared' flag, the collect program nicely groups all the static
  668. ctors/dtors for you into a list and sets up a function that will call
  669. them (Note: this means that this trick won't work if you use the GNU
  670. linker without collect (*note use GNU linker?::.).
  671.  
  672.    The magic is knowing these function names.  Currently, they're
  673. called:
  674.  
  675.      _GLOBAL__DI   <-- calls all module constructors
  676.      _GLOBAL__DD   <-- calls all module destructors
  677.  
  678.    [ possibly the leading underscore will differ between platforms:
  679. jbuck ]
  680.  
  681.    Therefore, if you make a wrapper around dlopen that looks up the
  682. symbol `_GLOBAL__DI' (or `__GLOBAL__DI' on SunOS4 machines), and calls
  683. it, you'll simulate getting the constructors called.
  684.  
  685.    You also need to set up the destructors to be called as well, so you
  686. need to put a wrapper around dlclose, which will call the `_GLOBAL__DD'
  687. function in the module when/if it's unloaded.
  688.  
  689.    Lastly, to get things 100% correct, you need to set up the
  690. destructors to also be called if the module is not unloaded, but the
  691. main program exits.  I do this by registering a single function with
  692. `atexit()' that calls all the destructors left in dynamically loaded
  693. modules.
  694.  
  695.    Check the file `README.SHLIB' from the libg++ distribution for more
  696. about making and using shared libraries.
  697.  
  698.    A patch is needed to build shared versions of version 2.7.2 of libg++
  699. and libstdc++ on the HP-PA architecture.  You can find the patch at
  700. `ftp://ftp.cygnus.com/pub/g++/libg++-2.7.2-hppa-gcc-fix'.
  701.  
  702. How do I use the new repository code?
  703. =====================================
  704.  
  705.    Because there is some disagreement about the details of the template
  706. repository mechanism, you'll need to obtain a patch from Cygnus Support
  707. to enable the 2.7.2 repository code.  You can obtain the patch by
  708. anonymous FTP: `ftp://ftp.cygnus.com/pub/g++/gcc-2.7.2-repo.gz'.
  709.  
  710.    There are patches for 2.7.0 and 2.7.1 in the same directory, though
  711. if you're going to rebuild the compiler you should use the latest one.
  712.  
  713.    If you're running NetBSD or BSDI, the Cygnus repo patch is not quite
  714. correct.  Tim Liddelow has made an alternate version available at
  715. `ftp://ftp.cst.com.au/pub/gcc-2.7.2-repo-bsd.gz'.
  716.  
  717.    After you've applied the patch, the `-frepo' flag will enable the
  718. repository mechanism.  The flag works much like the existing
  719. `-fno-implicit-templates' flag, except that auxiliary files, with an
  720. `.rpo' extension, are built that specify what template expansions are
  721. needed.  At link time, the (patched) collect program detects missing
  722. templates and recompiles some of the object files so that the required
  723. templates are expanded.
  724.  
  725.    Note that the mechanism differs from that of cfront in that template
  726. definitions still must be visible at the point where they are to be
  727. expanded.  No assumption is made that `foo.C' contains template
  728. definitions corresponding to template declarations in `foo.h'.
  729.  
  730.    Jason Merrill writes: "To perform closure on a set of objects, just
  731. try to link them together.  It will fail, but as a side effect all
  732. needed instances will be generated in the objects."
  733.  
  734. Known bugs and problems with the repo patch
  735. ===========================================
  736.  
  737.    "The `-frepo' won't expand templated friend functions!"
  738.  
  739.    This is a known bug; currently you'll have to explicitly instantiate
  740. friend functions when using `-frepo' due to this bug (in 2.7.0 through
  741. 2.7.2 at least).
  742.  
  743.    With earlier versions of the repo patch, there was a bug that happens
  744. when you have given a quoted command line switch, something like
  745.  
  746.      -D'MESSAGE="hello there"'
  747.  
  748.    The repo code tries to recompile files using the same flags you
  749. originally specified, but doesn't quote arguments that need quoting,
  750. resulting in failures in some cases.  This is no longer a problem with
  751. the 2.7.2 patch.
  752.  
  753. Should I use the GNU C library?
  754. ===============================
  755.  
  756.    At this point in time, no (unless you are running Linux or the GNU
  757. Hurd system).  The GNU C library is still very young, and libg++ still
  758. conflicts with it in some places.  Use your native C library unless you
  759. know a lot about the gory details of libg++ and gnu-libc.  This will
  760. probably change in the future.
  761.  
  762. Global constructors aren't being called
  763. =======================================
  764.  
  765.    "I've installed gcc and it almost works, but constructors and
  766. destructors for global objects and objects at file scope aren't being
  767. called.  What did I do wrong?"
  768.  
  769.    It appears that you are running on a platform that requires you to
  770. install either "collect2" or the GNU linker, and you have done neither.
  771. For more information, see the section discussing the GNU linker (*note
  772. use GNU linker?::.).
  773.  
  774.    On Solaris 2.x, you shouldn't need a collect program and GNU ld
  775. doesn't run.  If your global constructors aren't being called, you may
  776. need to install a patch, available from Sun, to fix your linker.  The
  777. number of the "jumbo patch" that applies is 101409-03.  Thanks to
  778. Russell Street (r.street@auckland.ac.nz) for this info.
  779.  
  780.    It appears that on IRIX, the collect2 program is not being installed
  781. by default during the installation process, though it is required; you
  782. can install it manually by executing
  783.  
  784.      make install-collect2
  785.  
  786.    from the gcc source directory after installing the compiler.  (I'm
  787. not certain for which versions of gcc this problem occurs, and whether
  788. it is still present).
  789.  
  790. Strange assembler errors when linking C++ programs
  791. ==================================================
  792.  
  793.    "I've installed gcc and it seemed to go OK, but when I attempt to
  794. link any C++ program, I'm getting strange errors from the assembler!
  795. How can that be?"
  796.  
  797.    The messages in question might look something like
  798.  
  799.      as: "/usr/tmp/cca14605.s", line 8: error: statement syntax
  800.      as: "/usr/tmp/cca14605.s", line 14: error: statement syntax
  801.  
  802.    (on a Sun, different on other platforms).  The important thing is
  803. that the errors come out at the link step, *not* when a C++ file is
  804. being compiled.
  805.  
  806.    Here's what's going on: the collect2 program uses the Unix "nm"
  807. program to obtain a list of symbols for the global constructors and
  808. destructors, and it builds a little assembly language module that will
  809. permit them all to be called.  If you're seeing this symptom, you have
  810. an old version of GNU nm somewhere on your path.  This old version
  811. prints out symbol names in a format that the collect2 program does not
  812. expect, so bad assembly code is generated.
  813.  
  814.    The solution is either to remove the old version of GNU nm from your
  815. path (and that of everyone else who uses g++), or to install a newer
  816. version (it is part of the GNU "binutils" package).  Recent versions of
  817. GNU nm do not have this problem.
  818.  
  819. Other problems building libg++
  820. ==============================
  821.  
  822.    "I am having trouble building libg++.  Help!"
  823.  
  824.    On some platforms (for example, Ultrix), you may see errors
  825. complaining about being unable to open dummy.o.  On other platforms
  826. (for example, SunOS), you may see problems having to do with the type
  827. of size_t.  The fix for these problems is to make libg++ by saying
  828. "make CC=gcc".  According to Per Bothner, it should no longer be
  829. necessary to specify "CC=gcc" for libg++-2.3.1 or later.
  830.  
  831.    "I built and installed libg++, but g++ can't find it.  Help!"
  832.  
  833.    The string given to `configure' that identifies your system must be
  834. the same when you install libg++ as it was when you installed gcc.
  835. Also, if you used the `--prefix' option to install gcc somewhere other
  836. than `/usr/local', you must use the same value for `--prefix' when
  837. installing libg++, or else g++ will not be able to find libg++.
  838.  
  839.    The toplevel Makefile in the libg++ 2.6.2 distribution is broken,
  840. which along with a bug in g++ 2.6.3 causes problems linking programs
  841. that use the libstdc++ complex classes.  A patch for this is available
  842. from `ftp://ftp.cygnus.com//pub/g++/libg++-2.6.2-fix.gz'.
  843.  
  844. But I'm *still* having problems with `size_t'!
  845. ==============================================
  846.  
  847.    "I did all that, and I'm *still* having problems with disagreeing
  848. definitions of size_t, SIZE_TYPE, and the type of functions like
  849. `strlen'."
  850.  
  851.    The problem may be that you have an old version of `_G_config.h'
  852. lying around.  As of libg++ version 2.4, `_G_config.h', since it is
  853. platform-specific, is inserted into a different directory; most include
  854. files are in `$prefix/lib/g++-include', but this file now lives in
  855. `$prefix/$arch/include'.  If, after upgrading your libg++, you find that
  856. there is an old copy of `_G_config.h' left around, remove it, otherwise
  857. g++ will find the old one first.
  858.  
  859. Do I need to rebuild libg++ to go with my new g++?
  860. ==================================================
  861.  
  862.    "After I upgraded g++ to the latest version, I'm seeing undefined
  863. symbols."
  864.  
  865.    or
  866.  
  867.    "If I upgrade to a new version of g++, do I need to reinstall
  868. libg++?"
  869.  
  870.    As a rule, the first two digits of your g++ and libg++ should be the
  871. same.  Normally when you do an upgrade in the "minor version number"
  872. (2.5.7 to 2.5.8, say) there isn't a need to rebuild libg++, but there
  873. have been a couple of exceptions in the past.
  874.  
  875. I want several versions of g++ and libg++ to co-exist.
  876. ======================================================
  877.  
  878.    I recommend against using the `-V' flag to make multiple versions of
  879. gcc/g++ co-exist, unless they are different minor releases that can use
  880. the same compiled version of libg++.  The reason is that all these
  881. versions will try to use the same libg++ version, which usually will
  882. not work.
  883.  
  884.    Instead, use the `--prefix' flag when configuring gcc.  Use a
  885. different value of `--prefix' for each gcc version.  Use the same value
  886. of `--prefix' when configuring libg++.  You can then have any number of
  887. co-existing gcc/libg++ pairs.  Symbolic links can be used so that users
  888. don't need to put all these different directories on their paths.
  889.  
  890.    One possible system to use is to set `--prefix' to
  891. `/usr/local/gcc-2.x.y' for version 2.x.y of gcc, and to link whichever
  892. version of gcc you wish to be the default into `/usr/local/bin/gcc' and
  893. `/usr/local/bin/g++'.
  894.  
  895. Trouble installing g++ and libg++ on Linux
  896. ==========================================
  897.  
  898.    "I've downloaded the latest g++ and libg++ and I'm trying to install
  899. them on Linux, and I'm having lots of problems."
  900.  
  901.    FSF releases of libg++ won't install on Linux unchanged, since Linux
  902. uses are part of the libio library from libg++ for its standard C
  903. library, only this is changed in a way that it clashes with libg++.
  904. This means that you'll need a patched version of libg++ for it to work.
  905.  
  906.    If you want to upgrade to a new gcc/libg++ combination, the easiest
  907. thing to do is to grab the prebuilt versions of gcc and libg++ for Linux
  908. from `ftp://tsx-11.mit.edu/pub/linux/packages/GCC'.  Follow the
  909. directions carefully.  If you want to build from source, you'll need a
  910. patch for libg++; the Linux developers have named the patched libg++
  911. version libg++-2.7.1.3 and there is a patch file in the above-named
  912. directory.
  913.  
  914.    See `http://sunsite.unc.edu/LDP/HOWTO/GCC-HOWTO.html', the Linux GCC
  915. HOWTO, for more on gcc/g++ and Linux.
  916.  
  917.    Linux is in the process of switching over to the GNU C library,
  918. version 2, which will become Linux libc version 6.  Once this process is
  919. complete, there's a good chance that the installation process on Linux
  920. will be smoother, but only experts should try making this new library
  921. work at this point.
  922.  
  923. Problems with g++ on Linux Slackware 3.0
  924. ========================================
  925.  
  926.    "When I try to compile the traditional Hello, world program on Linux,
  927. the compiler can't find `iostream.h'.  What's the deal?"
  928.  
  929.    You probably have the Slackware 3.0 release.  There's an error in the
  930. setup.  It's easy to fix, though; log in as root, and make a symbolic
  931. link:
  932.  
  933.      ln -s /usr/lib/g++-include /usr/include/g++
  934.  
  935. The Evolution of g++
  936. ********************
  937.  
  938.    This chapter discusses the evolution of g++ and describes what can
  939. be expected in the future.
  940.  
  941. What's new in version 2.7.x of gcc/g++
  942. ======================================
  943.  
  944.    [ This section is old now, since 2.8.x/egcs is the new stuff ] The
  945. latest 2.7.x version was 2.7.2.2, released February 10, 1997.  The only
  946. change between 2.7.2.1 and 2.7.2.2 is that support was added for using
  947. the GNU C library, version 2, on Linux; users not interested in that
  948. functionality have no reason to upgrade.  The previous version of
  949. gcc/g++ was 2.7.2.1, released August 14, 1996.  The libg++ version that
  950. should be used with any 2.7.x gcc/g++ is 2.7.2, released July 4, 1996.
  951.  
  952.    Note that gcc 2.7.2.1 just consists of several small patches to
  953. gcc-2.7.2.  The release is mainly intended to fix platform-specific
  954. bugs and does not affect the C++ "front end" of the compiler (the part
  955. that parses your C++ code).
  956.  
  957.    The 2.7.x releases represent a great deal of work on the part of the
  958. g++ maintainers to fix outstanding bugs and move the compiler closer to
  959. the current ANSI/ISO standards committee's working paper, including
  960. supporting many of the new features that have been added to the
  961. language.  I recommend that everyone read the NEWS file contained in the
  962. distribution (and that system administrators make the file available to
  963. their users).  I've borrowed liberally from this file here.
  964.  
  965.    If any features seem unfamiliar, you will probably want to look at
  966. the recently-released public review copy of the C++ Working Paper.  A
  967. new draft, dated 2 December 1996, has been released for public comment.
  968. You can find it on the web at `http://www.cygnus.com/misc/wp/' or
  969. `http://www.maths.warwick.ac.uk/c++/pub/wp/html/cd2/'.  See
  970. `http://www.setech.com/x3.html' or
  971. `http://www.maths.warwick.ac.uk/c++/pub/' to download the document in
  972. PostScript, PDF (Adobe Acrobat), HTML, or ASCII form.
  973.  
  974.    Here are the main points:
  975.  
  976.    * As described above, the scope of variables declared in the
  977.      initialization part of a for statement has been changed; such
  978.      variables are now visible only in the loop body.  Use
  979.      `-fno-for-scope' to get the old behavior.  You'll need this flag
  980.      to build groff version 1.09, Ptolemy, and many other free software
  981.      packages.
  982.  
  983.    * Code that does not use #pragma interface/implementation will most
  984.      likely shrink dramatically, as g++ now only emits the vtable for a
  985.      class in the translation unit where its first non-inline,
  986.      non-abstract virtual function is defined.
  987.  
  988.    * Support for automatic template instantiation has *not* been enabled
  989.      in the official distribution, due to a disagreement over design
  990.      philosophies.  But you can get a patch from Cygnus to turn it on;
  991.      retrieve the patch from
  992.      `ftp://ftp.cygnus.com/pub/g++/gcc-2.7.2-repo.gz' to patch
  993.      gcc-2.7.2 (there are also patches for earlier gcc versions).
  994.  
  995.    * *Note exceptions::
  996.  
  997.    * Support for Run-Time Type Identification has been added with
  998.      `-frtti'.  This support is still in alpha; one major restriction
  999.      is that any file compiled with `-frtti' must include `<typeinfo>'
  1000.      (*not* `typeinfo.h' as the NEWS file says).  Also, all C++ code
  1001.      you link with (including libg++) has to be built with `-frtti', so
  1002.      it's still tricky to use.
  1003.  
  1004.    * Synthesis of compiler-generated constructors, destructors and
  1005.      assignment operators is now deferred until the functions are used.
  1006.  
  1007.    * The parsing of expressions such as `a ? b : c = 1' has changed from
  1008.      `(a ? b : c) = 1' to `a ? b : (c = 1)'.  This is a new C/C++
  1009.      incompatibility brought to you by the ANSI/ISO standards committee.
  1010.  
  1011.    * The operator keywords and, and_eq, bitand, bitor, compl, not,
  1012.      not_eq, or, or_eq, xor and xor_eq are now supported.  Use `-ansi'
  1013.      or `-foperator-names' to enable them.
  1014.  
  1015.    * The `explicit' keyword is now supported.  `explicit' is used to
  1016.      mark constructors and type conversion operators that should not be
  1017.      used implicitly.
  1018.  
  1019.    * Handling of user-defined type conversion has been improved.
  1020.  
  1021.    * Explicit instantiation of template methods is now supported.  Also,
  1022.      `inline template class foo<int>;' can be used to emit only the
  1023.      vtable for a template class.
  1024.  
  1025.    * With -fcheck-new, g++ will check the return value of all calls to
  1026.      operator new, and not attempt to modify a returned null pointer.
  1027.  
  1028.    * collect2 now demangles linker output, and c++filt has become part
  1029.      of the gcc distribution.
  1030.  
  1031.    * Improvements to template instantiation: only members actually used
  1032.      are instantiated.  (Actually this is not quite true: some inline
  1033.      templates that are not successfully inlined may be expanded even
  1034.      though they are not needed).
  1035.  
  1036. The GNU Standard C++ Library
  1037. ============================
  1038.  
  1039.    The GNU Standard C++ Library (also called the "GNU ANSI C++ Library"
  1040. in places in the code) is not libg++, though it is included in the
  1041. libg++ distribution.  Rather, it contains classes and functions
  1042. required by the ANSI/ISO standard.  The copyright conditions are the
  1043. same as those for for the iostreams classes; the LGPL is not used
  1044. (*note legalities::.).
  1045.  
  1046.    This library, libstdc++, is in the libg++ distribution in versions
  1047. 2.6.2 and later.  It requires at least gcc 2.6.3 to build the
  1048. libg++-2.6.2 version; use at least gcc 2.7.0 to build the libg++ 2.7.0
  1049. version.  It contains a hacked-up version of HP's implementation of the
  1050. Standard Template Library (*note Standard Template Library::.).  I've
  1051. successfully used this Standard Template Library version to build a
  1052. number of the demos you'll see on various web pages.
  1053.  
  1054.    As of version 2.7.0, the streams classes are now in libstdc++
  1055. instead of libg++, and libiostream is being phased out (don't use it).
  1056. The g++ program searches this library.
  1057.  
  1058.    The maintainers of libg++ have de-emphasized work on the older
  1059. libg++ classes in favor of enhancing libstdc++ to cover the full
  1060. language, so while libg++ will always be available, enhancements to it
  1061. should not be expected.
  1062.  
  1063. User Problems
  1064. *************
  1065.  
  1066. Linker complains about missing virtual table
  1067. ============================================
  1068.  
  1069.    "I'm getting a message complaining about an undefined virtual table.
  1070. Is this a compiler bug?"
  1071.  
  1072.    (On platforms that run neither collect nor the GNU linker, like
  1073. Solaris, you may see an odd undefined symbol like "_vt.3foo", where foo
  1074. is a class name).
  1075.  
  1076.    This is probably because you are missing a definition for the first
  1077. (non-inline) virtual function of the class.  Since gcc-2.7.0, g++ uses
  1078. a trick borrowed from cfront: the .o file containing the definition for
  1079. the first non-inline virtual function for the class will also contain
  1080. the virtual function table.
  1081.  
  1082. gcc-2.7.0 breaks declarations in "for" statements!
  1083. ==================================================
  1084.  
  1085.    gcc-2.7.0 implements the new ANSI/ISO rule on the scope of variables
  1086. declared in for loops.
  1087.  
  1088.      for (int i = 1; i <= 10; i++) {
  1089.              // do something here
  1090.      }
  1091.      foo(i);
  1092.  
  1093.    In the above example, most existing C++ compilers would pass the
  1094. value 11 to the function `foo'.  In gcc 2.7 and in the ANSI/ISO working
  1095. paper, the scope of `i' is only the for loop body, so this is an error.
  1096. So that old code can be compiled, the new gcc has a flag
  1097. `-fno-for-scope' that causes the old rule to be used.
  1098.  
  1099.    As of 2.7.1, the compiler attempts to issue warnings about code that
  1100. has different meanings under the two sets of rules, but the code is not
  1101. perfect: the intent was that code that has valid, but different,
  1102. meanings under the ARM rules and the working paper rules would give
  1103. warnings but have the new behavior, and this doesn't seem to happen.
  1104.  
  1105.    The `-ffor-scope' flag under 2.7.1 and 2.7.2 gives the 2.7.0
  1106. behavior.
  1107.  
  1108. g++ seems to want a const constructor.  What's that?
  1109. ====================================================
  1110.  
  1111.    gcc-2.7.1 introduced a bug that causes the compiler to ask for a
  1112. const constructor (there's no such thing in C++) in certain situations
  1113. where a const object appears in a template class.  Most cases have been
  1114. fixed in gcc-2.7.2, but unfortunately not all.  Still, if you're running
  1115. gcc-2.7.1 and have this problem, upgrade to 2.7.2; it is a vast
  1116. improvement.
  1117.  
  1118.    The default constructor for the template `pair' in ObjectSpace's
  1119. implementation of STL triggers the bug in one place, for gcc 2.7.2.  If
  1120. you're using ObjectSpace<STL> and having this problem, simply change
  1121. the default constructor from
  1122.  
  1123.      os_pair () : first (T1 ()), second (T2 ()) {}
  1124.  
  1125.    to just
  1126.  
  1127.      os_pair () {}
  1128.  
  1129.    Once this is done, ObjectSpace<STL> works fairly well.
  1130.  
  1131. How to silence "unused parameter" warnings
  1132. ==========================================
  1133.  
  1134.    "When I use `-Wall' (or `-Wunused'), g++ warns about unused
  1135. parameters.  But the parameters have to be there, for use in derived
  1136. class functions.  How do I get g++ to stop complaining?"
  1137.  
  1138.    The answer is to simply omit the names of the unused parameters when
  1139. defining the function.  This makes clear, both to g++ and to readers of
  1140. your code, that the parameter is unused.  For example:
  1141.  
  1142.      int Foo::bar(int arg) { return 0; }
  1143.  
  1144.    will give a warning for the unused parameter `arg'.  To suppress the
  1145. warning write
  1146.  
  1147.      int Foo::bar(int) { return 0; }
  1148.  
  1149. g++ objects to a declaration in a case statement
  1150. ================================================
  1151.  
  1152.    "The compiler objects to my declaring a variable in one of the
  1153. branches of a case statement.  Earlier versions used to accept this
  1154. code.  Why?"
  1155.  
  1156.    The draft standard does not allow a goto or a jump to a case label to
  1157. skip over an initialization of a variable or a class object.  For
  1158. example:
  1159.  
  1160.      switch ( i ) {
  1161.        case 1:
  1162.          Object obj(0);
  1163.              ...
  1164.          break;
  1165.        case 2:
  1166.          ...
  1167.          break;
  1168.      }
  1169.  
  1170.    The reason is that `obj' is also in scope in the rest of the switch
  1171. statement.
  1172.  
  1173.    As of version 2.7.0, the compiler will object that the jump to the
  1174. second case level crosses the initialization of `obj'.  Older compiler
  1175. versions would object only if class Object has a destructor.  In either
  1176. case, the solution is to add a set of curly braces around the case
  1177. branch:
  1178.  
  1179.        case 1:
  1180.          {
  1181.             Object obj(0);
  1182.              ...
  1183.             break;
  1184.          }
  1185.  
  1186. Where can I find a demangler?
  1187. =============================
  1188.  
  1189.    A g++-compatible demangler named `c++filt' can be found in the
  1190. `binutils' distribution.  This distribution (which also contains the
  1191. GNU linker) can be found at any GNU archive site.
  1192.  
  1193.    As of version 2.7.0, `c++filt' is included with gcc and is installed
  1194. automatically.  Even better, it is used by the `collect' linker, so you
  1195. don't see mangled symbols anymore (except on platforms that use neither
  1196. collect nor the GNU linker, like Solaris).
  1197.  
  1198. Linker reports undefined symbols for static data members
  1199. ========================================================
  1200.  
  1201.    "g++ reports undefined symbols for all my static data members when I
  1202. link, even though the program works correctly for compiler XYZ.  What's
  1203. going on?"
  1204.  
  1205.    The problem is almost certainly that you don't give definitions for
  1206. your static data members.  If you have
  1207.  
  1208.      class Foo {
  1209.          ...
  1210.          void method();
  1211.          static int bar;
  1212.      };
  1213.  
  1214.    you have only declared that there is an int named Foo::bar and a
  1215. member function named Foo::method that is defined somewhere.  You still
  1216. need to define *both* method() and bar in some source file.  According
  1217. to the draft ANSI standard, you must supply an initializer, such as
  1218.  
  1219.      int Foo::bar = 0;
  1220.  
  1221. in one (and only one) source file.
  1222.  
  1223. What does "Internal compiler error" mean?
  1224. =========================================
  1225.  
  1226.    It means that the compiler has detected a bug in itself.
  1227. Unfortunately, g++ still has many bugs, though it is a lot better than
  1228. it used to be.  If you see this message, please send in a complete bug
  1229. report (see next section).
  1230.  
  1231. I think I have found a bug in g++.
  1232. ==================================
  1233.  
  1234.    "I think I have found a bug in g++, but I'm not sure.  How do I know,
  1235. and who should I tell?"
  1236.  
  1237.    First, see the excellent section on bugs and bug reports in the gcc
  1238. manual (which is included in the gcc distribution).  As a short summary
  1239. of that section: if the compiler gets a fatal signal, for any input,
  1240. it's a bug (newer versions of g++ will ask you to send in a bug report
  1241. when they detect an error in themselves).  Same thing for producing
  1242. invalid assembly code.
  1243.  
  1244.    When you report a bug, make sure to describe your platform (the type
  1245. of computer, and the version of the operating system it is running) and
  1246. the version of the compiler that you are running.  See the output of the
  1247. command `g++ -v' if you aren't sure.  Also provide enough code so that
  1248. the g++ maintainers can duplicate your bug.  Remember that the
  1249. maintainers won't have your header files; one possibility is to send
  1250. the output of the preprocessor (use `g++ -E' to get this).  This is
  1251. what a "complete bug report" means.
  1252.  
  1253.    I will add some extra notes that are C++-specific, since the notes
  1254. from the gcc documentation are generally C-specific.
  1255.  
  1256.    First, mail your bug report to "bug-g++@prep.ai.mit.edu".  You may
  1257. also post to `gnu.g++.bug', but it's better to use mail, particularly
  1258. if you have any doubt as to whether your news software generates
  1259. correct reply addresses.  Don't mail C++ bugs to
  1260. bug-gcc@prep.ai.mit.edu.
  1261.  
  1262.    *News:* as I write this (late February 1996) the gateway connecting
  1263. the bug-g++ mailing list and the `gnu.g++.bug' newsgroup is
  1264. (temporarily?) broken.  Please mail, do not post bug reports.
  1265.  
  1266.    If your bug involves libg++ rather than the compiler, mail to
  1267. bug-lib-g++@prep.ai.mit.edu.  If you're not sure, choose one, and if you
  1268. guessed wrong, the maintainers will forward it to the other list.
  1269.  
  1270.    Second, if your program does one thing, and you think it should do
  1271. something else, it is best to consult a good reference if in doubt.
  1272. The standard reference is the draft working paper from the ANSI/ISO C++
  1273. standardization committee, which you can get on the net.  For
  1274. PostScript and PDF (Adobe Acrobat) versions, see the archive at
  1275. `ftp://research.att.com/dist/stdc++/WP'.  For HTML and ASCII versions,
  1276. see `ftp://ftp.cygnus.com/pub/g++'.  On the World Wide Web, see
  1277. `http://www.cygnus.com/misc/wp/'.
  1278.  
  1279.    An older standard reference is "The Annotated C++ Reference Manual",
  1280. by Ellis and Stroustrup (copyright 1990, ISBN #0-201-51459-1).  This is
  1281. what they're talking about on the net when they refer to "the ARM".
  1282. But you should know that vast changes have been made to the language
  1283. since then.
  1284.  
  1285.    The ANSI/ISO C++ standards committee have adopted some changes to the
  1286. C++ language since the publication of the original ARM, and newer
  1287. versions of g++ (2.5.x and later) support some of these changes, notably
  1288. the mutable keyword (added in 2.5.0), the bool type (added in 2.6.0),
  1289. and changes in the scope of variables defined in for statements (added
  1290. in 2.7.0).  You can obtain an addendum to the ARM explaining many of
  1291. these changes by FTP from
  1292. `ftp://ftp.std.com/AW/stroustrup2e/new_iso.ps'.
  1293.  
  1294.    Note that the behavior of (any version of) AT&T's "cfront" compiler
  1295. is NOT the standard for the language.
  1296.  
  1297. Porting programs from other compilers to g++
  1298. ============================================
  1299.  
  1300.    "I have a program that runs on <some other C++ compiler>, and I want
  1301. to get it running under g++.  Is there anything I should watch out for?"
  1302.  
  1303.    Note that g++ supports many of the newer keywords that have recently
  1304. been added to the language.  Your other C++ compiler may not support
  1305. them, so you may need to rename variables and members that conflict
  1306. with these keywords.
  1307.  
  1308.    There are two other reasons why a program that worked under one
  1309. compiler might fail under another: your program may depend on the order
  1310. of evaluation of side effects in an expression, or it may depend on the
  1311. lifetime of a temporary (you may be assuming that a temporary object
  1312. "lives" longer than the standard guarantees).  As an example of the
  1313. first:
  1314.  
  1315.      void func(int,int);
  1316.      
  1317.      int i = 3;
  1318.      func(i++,i++);
  1319.  
  1320.    Novice programmers think that the increments will be evaluated in
  1321. strict left-to-right order.  Neither C nor C++ guarantees this; the
  1322. second increment might happen first, for example.  func might get 3,4,
  1323. or it might get 4,3.
  1324.  
  1325.    The second problem often happens with classes like the libg++ String
  1326. class.  Let's say I have
  1327.  
  1328.      String func1();
  1329.      void func2(const char*);
  1330.  
  1331.    and I say
  1332.  
  1333.      func2(func1());
  1334.  
  1335.    because I know that class String has an "operator const char*".  So
  1336. what really happens is
  1337.  
  1338.      func2(func1().convert());
  1339.  
  1340.    where I'm pretending I have a convert() method that is the same as
  1341. the cast.  This is unsafe in g++ versions before 2.6.0, because the
  1342. temporary String object may be deleted after its last use (the call to
  1343. the conversion function), leaving the pointer pointing to garbage, so by
  1344. the time func2 is called, it gets an invalid argument.
  1345.  
  1346.    Both the cfront and the old g++ behaviors are legal according to the
  1347. ARM, but the powers that be have decided that compiler writers were
  1348. given too much freedom here.
  1349.  
  1350.    The ANSI C++ committee has now come to a resolution of the lifetime
  1351. of temporaries problem: they specify that temporaries should be deleted
  1352. at end-of-statement (and at a couple of other points).  This means that
  1353. g++ versions before 2.6.0 now delete temporaries too early, and cfront
  1354. deletes temporaries too late.  As of version 2.6.0, g++ does things
  1355. according to the new standard.
  1356.  
  1357.    For now, the safe way to write such code is to give the temporary a
  1358. name, which forces it to live until the end of the scope of the name.
  1359. For example:
  1360.  
  1361.      String& tmp = func1();
  1362.      func2(tmp);
  1363.  
  1364.    Finally, like all compilers (but especially C++ compilers, it seems),
  1365. g++ has bugs, and you may have tweaked one.  If so, please file a bug
  1366. report (after checking the above issues).
  1367.  
  1368. Why does g++ mangle names differently from other C++ compilers?
  1369. ===============================================================
  1370.  
  1371.    See the answer to the next question.
  1372.  
  1373. Why can't g++ code link with code from other C++ compilers?
  1374. ===========================================================
  1375.  
  1376.    "Why can't I link g++-compiled programs against libraries compiled by
  1377. some other C++ compiler?"
  1378.  
  1379.    Some people think that, if only the FSF and Cygnus Support folks
  1380. would stop being stubborn and mangle names the same way that, say,
  1381. cfront does, then any g++-compiled program would link successfully
  1382. against any cfront-compiled library and vice versa.  Name mangling is
  1383. the least of the problems.  Compilers differ as to how objects are laid
  1384. out, how multiple inheritance is implemented, how virtual function
  1385. calls are handled, and so on, so if the name mangling were made the
  1386. same, your programs would link against libraries provided from other
  1387. compilers but then crash when run.  For this reason, the ARM
  1388. *encourages* compiler writers to make their name mangling different
  1389. from that of other compilers for the same platform.  Incompatible
  1390. libraries are then detected at link time, rather than at run time.
  1391.  
  1392. What documentation exists for g++ 2.x?
  1393. ======================================
  1394.  
  1395.    Relatively little.  While the gcc manual that comes with the
  1396. distribution has some coverage of the C++ part of the compiler, it
  1397. focuses mainly on the C compiler (though the information on the "back
  1398. end" pertains to C++ as well).  Still, there is useful information on
  1399. the command line options and the #pragma interface and #pragma
  1400. implementation directives in the manual, and there is a useful section
  1401. on template instantiation in the 2.6 version.  There is a Unix-style
  1402. manual entry, "g++.1", in the gcc-2.x distribution; the information
  1403. here is a subset of what is in the manual.
  1404.  
  1405.    You can buy a nicely printed and bound copy of this manual from the
  1406. FSF; see above for ordering information.
  1407.  
  1408.    A draft of a document describing the g++ internals appears in the gcc
  1409. distribution (called g++int.texi); it is incomplete but gives lots of
  1410. information.
  1411.  
  1412.    For class libraries, there are several resources available:
  1413.  
  1414.    * The libg++ distribution has a manual `libg++/libg++.texi'
  1415.      describing the old libg++ classes, and another manual
  1416.      `libio/iostream.texi' describing the iostreams implementation.
  1417.  
  1418.    * While there is no libg++-specific document describing the STL
  1419.      implementation, SGI's web site, at
  1420.      `http://www.sgi.com/Technology/STL/', is an excellent resource.
  1421.      Note that the SGI version of STL is the one that is included with
  1422.      the egcs and 2.8.x releases of g++/libstdc++.
  1423.  
  1424. Problems with the template implementation
  1425. =========================================
  1426.  
  1427.    g++ does not implement a separate pass to instantiate template
  1428. functions and classes at this point; for this reason, it will not work,
  1429. for the most part, to declare your template functions in one file and
  1430. define them in another.  The compiler will need to see the entire
  1431. definition of the function, and will generate a static copy of the
  1432. function in each file in which it is used.
  1433.  
  1434.    (The experimental template repository code (*note repository::.) that
  1435. can be added to 2.7.0 or later does implement a separate pass, but there
  1436. is still no searching of files that the compiler never saw).
  1437.  
  1438.    As of 2.8.x and egcs-1.0.x, the template implementation has most of
  1439. the features specified in the draft standard.  Still missing are
  1440. template arguments that are themselves templates; however, template
  1441. class member functions work, and most of the limitations of the older
  1442. g++ versions are fixed.
  1443.  
  1444.    I think that given this new implementation, it should not be
  1445. necessary for users to mess around with switches like
  1446. `-fno-implicit-templates' and `#pragma' directives; most of the time,
  1447. the default behavior will work OK.  Users of older versions might want
  1448. to read on.
  1449.  
  1450.    For version 2.6.0, however, a new switch `-fno-implicit-templates'
  1451. was added; with this switch, templates are expanded only under user
  1452. control.  I recommend that all g++ users that use templates read the
  1453. section "Template Instantiation" in the gcc manual (version 2.6.x and
  1454. newer).  g++ now supports explicit template expansion using the syntax
  1455. from the latest C++ working paper:
  1456.  
  1457.      template class A<int>;
  1458.      template ostream& operator << (ostream&, const A<int>&);
  1459.  
  1460.    As of version 2.7.2, there are still a few limitations in the
  1461. template implementation besides the above (thanks to Jason Merrill for
  1462. this info):
  1463.  
  1464.    *Note*: these problems are eliminated in egcs and in gcc-2.8.x.
  1465.  
  1466.   1. Static data member templates are not supported in compiler
  1467.      versions older than 2.8.0.  You can work around this by explicitly
  1468.      declaring the static variable for each template specialization:
  1469.  
  1470.           template <class T> struct A {
  1471.             static T t;
  1472.           };
  1473.           
  1474.           template <class T> T A<T>::t = 0; // gets bogus error
  1475.           int A<int>::t = 0;                // OK (workaround)
  1476.  
  1477.   2. Template member names are not available when defining member
  1478.      function templates.
  1479.  
  1480.           template <class T> struct A {
  1481.             typedef T foo;
  1482.             void f (foo);
  1483.             void g (foo arg) { ... }; // this works
  1484.           };
  1485.           
  1486.           template <class T> void A<T>::f (foo) { } // gets bogus error
  1487.  
  1488.   3. Templates are instantiated using the parser.  This results in two
  1489.      problems (again, these problems are fixed in 2.8.0 and egcs):
  1490.  
  1491.      a) Class templates are instantiated in some situations where such
  1492.      instantiation should not occur.
  1493.  
  1494.           template <class T> class A { };
  1495.           A<int> *aip = 0; // should not instantiate A<int> (but does)
  1496.  
  1497.      b) Function templates cannot be inlined at the site of their
  1498.      instantiation.
  1499.  
  1500.           template <class T> inline T min (T a, T b) { return a < b ? a : b; }
  1501.           
  1502.           void f () {
  1503.             int i = min (1, 0);           // not inlined
  1504.           }
  1505.           
  1506.           void g () {
  1507.             int j = min (1, 0);           // inlined
  1508.           }
  1509.  
  1510.      A workaround that works in version 2.6.1 through 2.7.2.x is to
  1511.      specify
  1512.  
  1513.           extern template int min (int, int);
  1514.  
  1515.      before `f()'; this will force it to be instantiated (though not
  1516.      emitted).
  1517.  
  1518.      *Note:* this kind of "guiding declaration" is not standard and
  1519.      isn't supported by egcs or gcc-2.8.x, as the standard says that
  1520.      this declares a "normal" `min' function which has no relation to
  1521.      the template function `min<int>(int,int)'.  But then the new
  1522.      compilers have no problem inlining template functions.
  1523.  
  1524.   4. Member function templates are always instantiated when their
  1525.      containing class is.  This is wrong (fixed in egcs/2.8).
  1526.  
  1527. I get undefined symbols when using templates
  1528. ============================================
  1529.  
  1530.    (Thanks to Jason Merrill for this section).
  1531.  
  1532.    g++ does not automatically instantiate templates defined in other
  1533. files.  Because of this, code written for cfront will often produce
  1534. undefined symbol errors when compiled with g++.  You need to tell g++
  1535. which template instances you want, by explicitly instantiating them in
  1536. the file where they are defined.  For instance, given the files
  1537.  
  1538.    `templates.h':
  1539.      template <class T>
  1540.      class A {
  1541.      public:
  1542.        void f ();
  1543.        T t;
  1544.      };
  1545.      
  1546.      template <class T> void g (T a);
  1547.  
  1548.    `templates.cc':
  1549.      #include "templates.h"
  1550.      
  1551.      template <class T>
  1552.      void A<T>::f () { }
  1553.      
  1554.      template <class T>
  1555.      void g (T a) { }
  1556.  
  1557.    main.cc:
  1558.      #include "templates.h"
  1559.      
  1560.      main ()
  1561.      {
  1562.        A<int> a;
  1563.        a.f ();
  1564.        g (a);
  1565.      }
  1566.  
  1567.    compiling everything with `g++ main.cc templates.cc' will result in
  1568. undefined symbol errors for `A<int>::f ()' and `g (A<int>)'.  To fix
  1569. these errors, add the lines
  1570.  
  1571.      template class A<int>;
  1572.      template void g (A<int>);
  1573.  
  1574.    to the bottom of `templates.cc' and recompile.
  1575.  
  1576. I get multiply defined symbols using templates
  1577. ==============================================
  1578.  
  1579.    You may be running into a bug that was introduced in version 2.6.1
  1580. (and is still present in 2.6.3) that generated external linkage for
  1581. templates even when neither `-fexternal-templates' nor
  1582. `-fno-implicit-templates' is specified.  There is a patch for this
  1583. problem at
  1584. `ftp://ftp.cygnus.com/pub/g++/gcc-2.6.3-template-fix'.
  1585.  
  1586.    I recommend either applying the patch or using
  1587. `-fno-implicit-templates' together with explicit template instantiation
  1588. as described in previous sections.
  1589.  
  1590.    This bug is fixed in 2.7.0.
  1591.  
  1592. Does g++ support the Standard Template Library?
  1593. ===============================================
  1594.  
  1595.    If you want to use the Standard Template Library, do not pass go,
  1596. upgrade immediately to gcc-2.8.x or to egcs.  The new C++ front end
  1597. handles STL very well, and the high-quality implementation of STL from
  1598. SGI is included verbatim as part of the libstdc++ class library.
  1599.  
  1600.    If for some reason you must use 2.7.2, you can probably get by with
  1601. the hacked-up version of the old implementation from HP that is
  1602. included with libg++-2.7.2, but it is definitely inferior and has more
  1603. problems.  Alternatively, g++ 2.7.2.x users might try the following: a
  1604. group at the Moscow Center for Sparc Technology has a port of the SGI
  1605. STL implementation that mostly works with gcc-2.7.2.  See
  1606. `http://www.ipmce.su/people/fbp/stl/stlport.html'.
  1607.  
  1608.    Mumit Khan has produced an "STL newbie guide" with lots of
  1609. information on using STL with gcc.  See
  1610.  
  1611.    `http://www.xraylith.wisc.edu/~khan/software/stl/STL.newbie.html'
  1612.  
  1613. I'm having problems mixing STL and the standard string class
  1614. ============================================================
  1615.  
  1616.    [ This section is for g++ 2.7.2.x users only ]
  1617.  
  1618.    This is due to a bug in g++ version 2.7.2 and 2.7.2.1; the compiler
  1619. is confused by the operator declarations.  There is an easy workaround,
  1620. however; just make sure that the `<string>' header is included before
  1621. any STL headers.  That is, just say
  1622.  
  1623.      #include <string>
  1624.  
  1625.    before any other `#include' directives.
  1626.  
  1627.    Unfortunately, this doesn't solve all problems; you may still have
  1628. difficulty with the relational operators !=, <=, >, and >=, thanks to a
  1629. conflict with the very general definition of these operators in
  1630. function.h.  One trick that sometimes works is to try to use == and <
  1631. in your code instead of the other operators.  Another is to use a
  1632. derived class of <string>.  The only completely satisfactory solution,
  1633. I'm afraid, is to wait for the new release.
  1634.  
  1635. Problems and limitations with exceptions
  1636. ========================================
  1637.  
  1638.    The first really usable exceptions implementations are in 2.8.x and
  1639. egcs.  With these versions, exceptions are enabled by default; use
  1640. -fno-exceptions to disable exceptions.
  1641.  
  1642.    However, 2.8.1 still has not integrated egcs work that computes an
  1643. accurate control flow graph in the presence of exceptions.  For this
  1644. reason, you will sometimes get bogus warnings when compiling with 2.8.1,
  1645. -O, and -Wall, about uninitialized variables and the like.
  1646.  
  1647.    2.7.2.x has very limited and partially broken support for exceptions.
  1648. With that compiler, you must provide the `-fhandle-exceptions' flag to
  1649. enable exception handling.  In version 2.7.2 and older, exceptions may
  1650. not work properly (and you may get odd error messages when compiling)
  1651. if you turn on optimization (the `-O' flag).  If you care about
  1652. exceptions, please upgrade to a newer compiler!
  1653.  
  1654.    In 2.7.2, you must give the `-frtti' switch to enable catching of
  1655. derived exception objects with handlers for the base exception class;
  1656. if `-frtti' is not given, only exact type matching works.
  1657.  
  1658.    For exception handling to work with 2.7.0 your CPU must be a SPARC,
  1659. RS6000/PowerPC, 386/486/Pentium, or ARM.  Release 2.7.1 added support
  1660. for the Alpha, and "m68k is rumored to work on some platforms" and "VAX
  1661. may also work" (according to Mike Stump).  *It still doesn't work on
  1662. HP-PA or MIPS platforms.*
  1663.  
  1664.    Exception handling adds space overhead (the size of the executable
  1665. grows); the problem is worse on the ix86 (Intel-like) architecture than
  1666. on RISC architectures.  The extra exceptions code is generated in a
  1667. separate program section and is only paged in if an exception is
  1668. thrown, so the cost is in disk, not in RAM or CPU.
  1669.  
  1670.    Exception overhead is much lower on ix86 if you use binutils 2.9 or
  1671. later, as gas (the GNU assembler) can now compress the information.
  1672.  
  1673. Does g++ support namespaces?
  1674. ============================
  1675.  
  1676.    As of version 2.7.2, g++ recognizes the keywords `namespace' and
  1677. `using', and there is some rudimentary code present, but almost nothing
  1678. connected with namespaces works yet.  The new versions (2.8.x/egcs)
  1679. still lack namespace support, but to help compile standard programs
  1680. they make
  1681.  
  1682.      using namespace std;
  1683.  
  1684.    a no-op.  There is namespace implementation work going on in the egcs
  1685. snapshots (but it hasn't been released yet).
  1686.  
  1687. What are the differences between g++ and the ARM specification of C++?
  1688. ======================================================================
  1689.  
  1690.    Up until recently, there was no really usable exception support.  If
  1691. you need exceptions, you want gcc-2.8.x or egcs.  The implementation
  1692. works fairly well.  The 2.7.x version was strictly alpha quality and
  1693. quite fragile.
  1694.  
  1695.    Some features that the ANSI/ISO standardization committee has voted
  1696. in that don't appear in the ARM are supported, notably the `mutable'
  1697. keyword, in version 2.5.x.  2.6.x added support for the built-in boolean
  1698. type `bool', with constants `true' and `false'.  Run-time type
  1699. identification was rudimentary in 2.7.x but is fully supported in
  1700. 2.8.x, so there are more reserved words: `typeid', `static_cast',
  1701. `reinterpret_cast', `const_cast', and `dynamic_cast'.
  1702.  
  1703.    As with any beta-test compiler, there are bugs.  You can help improve
  1704. the compiler by submitting detailed bug reports.
  1705.  
  1706.    [ This paragraph obsoleted by 2.8.x/egcs: ] One of the weakest areas
  1707. of g++ other than templates is the resolution of overloaded functions
  1708. and operators in complex cases.  The usual symptom is that in a case
  1709. where the ARM says that it is ambiguous which function should be
  1710. chosen, g++ chooses one (often the first one declared).  This is
  1711. usually not a problem when porting C++ code from other compilers to
  1712. g++, but shows up as errors when code developed under g++ is ported to
  1713. other compilers.  (I believe this is no longer a significant problem in
  1714. 2.7.0 or later).
  1715.  
  1716.    [A full bug list would be very long indeed, so I won't put one here;
  1717. the sheer complexity of the C++ language means that every compiler I've
  1718. tried has some problems. 2.8.x and egcs are a big improvement]
  1719.  
  1720. Will g++ compile InterViews?  The NIH class library?  Rogue Wave?
  1721. =================================================================
  1722.  
  1723.    The NIH class library uses a non-portable, compiler-dependent hack
  1724. to initialize itself, which makes life difficult for g++ users.  It
  1725. will not work without modification, and I don't know what modifications
  1726. are required or whether anyone has done them successfully.
  1727.  
  1728.    In short, it's not going to happen any time soon (previous FAQs
  1729. referred to patches that a new NIHCL release would hopefully contain,
  1730. but this hasn't happened).
  1731.  
  1732.    *Note:* I thought I saw an item indicating that someone *had*
  1733. patched NIHCL to work with g++.  Any pointers?
  1734.  
  1735.    I think that as of version 2.5.6, the standard g++ will compile the
  1736. standard 3.1 InterViews completely successfully.  Note that you'll need
  1737. the `-fno-for-scope' flag if you use gcc-2.7.0; with 2.7.2 you may be
  1738. able to omit this flag but you'll get warnings.
  1739.  
  1740.    According to Jason Merrill, gcc-2.7.0 and newer works with Rogue
  1741. Wave's `tools.h++' class library, but you may want to grab
  1742. `ftp://ftp.cygnus.com/pub/g++/Tools.h++-6.1-patch'.  Again, you'll need
  1743. the `-fno-for-scope' flag since Rogue Wave hasn't fixed their code to
  1744. comply with the new standard yet.
  1745.  
  1746. Debugging on SVR4 systems
  1747. =========================
  1748.  
  1749.    "How do I get debugging to work on my System V Release 4 system?"
  1750.  
  1751.    Most systems based on System V Release 4 (except Solaris) encode
  1752. symbolic debugging information in a format known as `DWARF'.  There are
  1753. two forms of DWARF, DWARF 1 and DWARF 2.  The default is often DWARF 1,
  1754. which is not really expressive enough to do C++ correctly.
  1755.  
  1756.    Now that we have gdb 4.17, DWARF debugging is finally supported (if
  1757. you use gcc 2.8.1 or egcs-1.0.x or newer).
  1758.  
  1759.    For users of older versions of the tools, you *can* get g++
  1760. debugging under SVR4 systems by configuring gcc with the `--with-stabs'
  1761. option.  This causes gcc to use an alternate debugging format, one more
  1762. like that used under SunOS4.  You won't need to do anything special to
  1763. GDB; it will always understand the "stabs" format.
  1764.  
  1765.    To specify DWARF 2 output on Unixware, you can give the `-ggdb'
  1766. switch; alternatively, `-gstabs' produces "stabs" format.
  1767.  
  1768. debugging problems on Solaris
  1769. =============================
  1770.  
  1771.    "I'm on Solaris, and gdb says it doesn't know about some of my local
  1772. symbols.  Help!"
  1773.  
  1774.    This problem was introduced in gcc 2.7.2; debug symbols for locals
  1775. that aren't declared at the beginning of a block come out in the wrong
  1776. order, and gdb can't find such symbols.
  1777.  
  1778.    This problem is fixed in gcc-2.7.2.1.
  1779.  
  1780. X11 conflicts with libg++ in definition of String
  1781. =================================================
  1782.  
  1783.    "X11 and Motif define String, and this conflicts with the String
  1784. class in libg++.  How can I use both together?"
  1785.  
  1786.    One possible method is the following:
  1787.  
  1788.      #define String XString
  1789.      #include <X11/Intrinsic.h>
  1790.      /* include other X11 and Motif headers */
  1791.      #undef String
  1792.  
  1793.    and remember to use the correct `String' or `XString' when you
  1794. declare things later.
  1795.  
  1796. Why can't I assign one stream to another?
  1797. =========================================
  1798.  
  1799.    [ Thanks to Per Bothner and Jerry Schwarz for this section. ]
  1800.  
  1801.    Assigning one stream to another seems like a reasonable thing to do,
  1802. but it's a bad idea.  Usually, this comes up because people want to
  1803. assign to `cout'.  This is poor style, especially for libraries, and is
  1804. contrary to good object-oriented design.  (Libraries that write directly
  1805. to `cout' are less flexible, modular, and object-oriented).
  1806.  
  1807.    The iostream classes do not allow assigning to arbitrary streams,
  1808. because this can violate typing:
  1809.  
  1810.      ifstream foo ("foo");
  1811.      istrstream str(...);
  1812.      foo = str;
  1813.      foo->close ();  /* Oops! Not defined for istrstream! */
  1814.  
  1815.    The original cfront implementation of iostreams by Jerry Schwarz
  1816. allows you to assign to `cin', `cout', `cerr', and `clog', but this is
  1817. not part of the draft standard for iostreams and generally isn't
  1818. considered a good idea, so standard-conforming code shouldn't use this
  1819. technique.
  1820.  
  1821.    The GNU implementation of iostream did not support assigning to
  1822. `cin', `cout', `cerr', and `clog' for quite a while, but it now does,
  1823. for backward compatibility with cfront iostream (versions 2.6.1 and
  1824. later of libg++).
  1825.  
  1826.    The ANSI/ISO C++ Working Paper does provide ways of changing the
  1827. streambuf associated with a stream.  Assignment isn't allowed; there is
  1828. an explicit named member that must be used.
  1829.  
  1830.    However, it is not wise to do this, and the results are confusing.
  1831. For example: `fstream::rdbuf' is supposed to return the *original*
  1832. filebuf, not the one you assigned. (This is not yet implemented in GNU
  1833. iostream.)  This must be so because `fstream::rdbuf' is defined to
  1834. return a `filebuf *'.
  1835.  
  1836. What are the rules for shipping code built with g++ and libg++?
  1837. ***************************************************************
  1838.  
  1839.    "Is it is possible to distribute programs for profit that are created
  1840. with g++ and use the g++ libraries?"
  1841.  
  1842.    I am not a lawyer, and this is not legal advice.  In any case, I have
  1843. little interest in telling people how to violate the spirit of the GNU
  1844. licenses without violating the letter.  This section tells you how to
  1845. comply with the intention of the GNU licenses as best I understand them.
  1846.  
  1847.    The FSF has no objection to your making money.  Its only interest is
  1848. that source code to their programs, and libraries, and to modified
  1849. versions of their programs and libraries, is always available.
  1850.  
  1851.    The short answer is that you do not need to release the source to
  1852. your program, but you can't just ship a stripped executable either,
  1853. unless you use only the subset of libg++ that includes the iostreams
  1854. classes (see discussion below) or the new libstdc++ library (available
  1855. in libg++ 2.6.2 and later).
  1856.  
  1857.    Compiling your code with a GNU compiler does not affect its
  1858. copyright; it is still yours.  However, in order to ship code that
  1859. links in a GNU library such as libg++ there are certain rules you must
  1860. follow.  The rules are described in the file COPYING.LIB that
  1861. accompanies gcc distributions; it is also included in the libg++
  1862. distribution.  See that file for the exact rules.  The agreement is
  1863. called the Library GNU Public License or LGPL.  It is much "looser"
  1864. than the GNU Public License, or GPL, that covers must GNU programs.
  1865.  
  1866.    Here's the deal: let's say that you use some version of libg++,
  1867. completely unchanged, in your software, and you want to ship only a
  1868. binary form of your code.  You can do this, but there are several
  1869. special requirements.  If you want to use libg++ but ship only object
  1870. code for your code, you have to ship source for libg++ (or ensure
  1871. somehow that your customer already has the source for the exact version
  1872. you are using), and ship your application in linkable form.  You cannot
  1873. forbid your customer from reverse-engineering or extending your program
  1874. by exploiting its linkable form.
  1875.  
  1876.    Furthermore, if you modify libg++ itself, you must provide source
  1877. for your modifications (making a derived class does not count as
  1878. modifying the library - that is "a work that uses the library").
  1879.  
  1880.    For certain portions of libg++ that implement required parts of the
  1881. C++ language (such as iostreams and other standard classes), the FSF has
  1882. loosened the copyright requirement still more by adding the "special
  1883. exception" clause, which reads as follows:
  1884.  
  1885.      As a special exception, if you link this library with files
  1886.      compiled with GCC to produce an executable, this does not cause
  1887.      the resulting executable to be covered by the GNU General Public
  1888.      License.  This exception does not however invalidate any other
  1889.      reasons why the executable file might be covered by the GNU
  1890.      General Public License.
  1891.  
  1892.    If your only use of libg++ uses code with this exception, you may
  1893. ship stripped executables or license your executables under different
  1894. conditions without fear of violating an FSF copyright.  It is the intent
  1895. of FSF and Cygnus that, as the other classes required by the ANSI/ISO
  1896. draft standard are developed, these will also be placed under this
  1897. "special exception" license.  The code in the new libstdc++ library,
  1898. intended to implement standard classes as defined by ANSI/ISO, is also
  1899. licensed this way.
  1900.  
  1901.    To avoid coming under the influence of the LGPL, you can link with
  1902. `-liostream' rather than `-lg++' (for version 2.6.x and earlier), or
  1903. `-lstdc++' now that it is available.  In version 2.7.0 all the standard
  1904. classes are in `-lstdc++'; you can do the link step with `c++' instead
  1905. of `g++' to search only the `-lstdc++' library and avoid the LGPL'ed
  1906. code in `-lg++'.
  1907.  
  1908.    Note that in egcs and in gcc-2.8.x, if you do not specify any
  1909. libraries the `g++' command will only link in `-lstdc++', so your
  1910. executable will not be affected by the LGPL (unless you link in some
  1911. other LGPLed library: the GNU C library used on GNU/Linux systems is
  1912. one such library).
  1913.  
  1914.    If you wish to discuss legal issues connected with GNU software on
  1915. the net, please use `gnu.misc.discuss', not the technical newsgroups.
  1916.  
  1917. -- 
  1918. -- Joe Buck
  1919. See my daughter: http://www.byoc.com/homepage/130481/molly.html
  1920. Boring semi-official web page:
  1921.                  http://www.synopsys.com/news/pubs/research/people/jbuck.html
  1922.