| \input texinfo.tex @c -*-texinfo-*- |
| @c %**start of header |
| @setfilename g++FAQ.info |
| @settitle Frequently asked questions about the GNU C++ compiler |
| @setchapternewpage off |
| @c version: @(#)g++FAQ.texi 1.56 09/15/97 |
| @c %**end of header |
| |
| @iftex |
| @finalout |
| @end iftex |
| @titlepage |
| @title G++ FAQ |
| @subtitle Frequently asked questions about the GNU C++ compiler |
| @subtitle September 14, 1997 |
| @sp 1 |
| @author Joe Buck |
| @page |
| @end titlepage |
| |
| @ifinfo |
| @node Top, basics, (dir), (dir) |
| @top |
| @unnumbered FAQ for g++ and libg++, by Joe Buck (jbuck@@synopsys.com) |
| @end ifinfo |
| |
| @cindex FAQ for g++, latest version |
| @cindex Archive site for FAQ lists |
| @cindex rtfm.mit.edu |
| @cindex Joe Buck <jbuck@@synopsys.com> |
| @cindex FAQ for C++ |
| |
| This is a list of frequently asked questions (FAQ) for g++ users; thanks to |
| all those who sent suggestions for improvements. Thanks to Marcus Speh |
| for doing the index. A hypertext version is available on the World Wide |
| Web at @file{http://www.cygnus.com/misc/g++FAQ_toc.html}. |
| |
| This document has just been reorganized a bit. There is some new |
| information about upcoming g++ releases and egcs; more needs to be done |
| but that will need to wait for next time. A diff would look misleadingly |
| large, since I blew away and rebuilt the texinfo menus. |
| |
| Please send updates and corrections to the FAQ to |
| @code{jbuck@@synopsys.com}. Please do @emph{not} use me as a resource |
| to get your questions answered; that's what @file{gnu.g++.help} is for and I |
| don't have the time to support the net's use of g++. |
| |
| Many FAQs, including this one, are available on the archive site |
| ``rtfm.mit.edu''; see @* |
| @file{ftp://rtfm.mit.edu/pub/usenet/news.answers}. |
| This FAQ may be found in the subdirectory g++-FAQ. |
| |
| @cindex Marshall Cline |
| @cindex comp.lang.c++ |
| @cindex C++ FAQ |
| This FAQ is intended to supplement, not replace, Marshall Cline's |
| excellent FAQ for the C++ language and for the newsgroup |
| @file{comp.lang.c++}. Especially if g++ is the first C++ |
| compiler you've ever used, the question ``How do I do <X> with g++?'' |
| is probably really ``How do I do <X> in C++?''. |
| You can find this FAQ at |
| @file{ftp://rtfm.mit.edu/pub/usenet/comp.lang.c++}, |
| or in HTML form at @file{http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/}. |
| |
| @menu |
| * basics:: What is g++? How do I get it? |
| * installation:: How to install, installation problems |
| * evolution:: The Evolution of g++ |
| * User Problems:: Commonly reported problems and bugs |
| * legalities:: Lawyer stuff, GPL, LGPL, etc. |
| * index:: Index of terms |
| |
| --- The Detailed Node Listing --- |
| |
| The basics: what is g++? |
| |
| * latest versions:: |
| * g++ for Unix:: |
| * g++ for HP:: |
| * g++ for Solaris 2.x:: |
| * g++ for other platforms:: |
| * 1.x vs 2.x versions:: |
| |
| Installation Issues and Problems |
| |
| * gcc-2 + g++-1:: |
| * what else do I need?:: |
| * use GNU linker?:: |
| * Use GNU assembler?:: |
| * shared libraries:: |
| * repository:: |
| * repo bugs:: |
| * Use GNU C library?:: |
| * Global constructor problems:: |
| * Strange assembler errors:: |
| * Other problems building libg++:: |
| * More size_t problems:: |
| * Rebuild libg++?:: |
| * co-existing versions:: |
| * Installing on Linux:: |
| * Linux Slackware 3.0:: |
| |
| The Evolution of g++ |
| |
| * version 2.7.x:: |
| * libstdc++:: |
| * new work:: |
| * egcs:: |
| * When?:: |
| |
| User Problems |
| |
| * missing virtual table:: |
| * for scope:: |
| * const constructor:: |
| * unused parameter warnings:: |
| * jump crosses initialization:: |
| * Demangler:: |
| * static data members:: |
| * internal compiler error:: |
| * bug reports:: |
| * porting to g++:: |
| * name mangling:: |
| * problems linking with other libraries:: |
| * documentation:: |
| * templates:: |
| * undefined templates:: |
| * redundant templates:: |
| * Standard Template Library:: |
| * STL and string:: |
| * exceptions:: |
| * namespaces:: |
| * agreement with standards:: |
| * compiling standard libraries:: |
| * debugging on SVR4 systems:: |
| * debugging problems on Solaris:: |
| * X11 conflicts with libg++:: |
| * assignment to streams:: |
| @end menu |
| |
| @node basics, installation, Top, Top |
| @chapter The basics: what is g++? |
| |
| @cindex Free Software Foundation |
| @cindex GNU Public License |
| @cindex GPL |
| |
| g++ is the traditional nickname of GNU C++, a freely redistributable |
| C++ compiler produced by the Free Software Foundation plus dozens of |
| skilled volunteers. I say ``traditional nickname'' because the GNU |
| compiler suite, gcc, bundles together compilers for C, Objective-C, |
| and C++ in one package. |
| |
| While the source code to gcc/g++ can be downloaded for free, |
| it is not public domain, but is protected by the GNU Public License, |
| or GPL (@pxref{legalities}). |
| |
| @menu |
| * latest versions:: |
| * g++ for Unix:: |
| * g++ for HP:: |
| * g++ for Solaris 2.x:: |
| * g++ for other platforms:: |
| * 1.x vs 2.x versions:: |
| @end menu |
| |
| @node latest versions, g++ for Unix, basics, basics |
| @section What is the latest version of gcc, g++, and libg++? |
| |
| @cindex gcc/g++, version date |
| The current version of gcc/g++ is 2.7.2.3, released August 20, 1997. |
| Although that looks very recent, the only change is a minor patch to |
| resolve a problem with Linux and the GNU C library; users not interested |
| in that functionality have no reason to upgrade. |
| |
| The current version of libg++ is 2.7.2, released July 4, 1996. |
| The last release of gcc/g++ with improvements to the C++ front end was |
| 2.7.2, released Nov. 25, 1995, nearly two years ago. |
| |
| I would strongly recommend that anyone using a g++ version earlier |
| than 2.7.2 should upgrade if at all possible (@pxref{version 2.7.x}). |
| |
| For some non-Unix platforms, the latest port of gcc may be an earlier |
| version (2.6.3, say). You'll need to use a version of libg++ that |
| has the same first two digits as the compiler version, e.g. use libg++ |
| 2.6.x (for the latest x you can find) with gcc version 2.6.3. |
| |
| The latest "1.x" version of gcc is 1.42, and the latest "1.x" version of |
| g++ is 1.42.0. |
| While gcc 1.42 is quite usable for C programs, |
| I recommend against using g++ 1.x except in special circumstances |
| (and I can't think of any such circumstances). |
| |
| @node g++ for Unix, g++ for HP, latest versions, basics |
| @section How do I get a copy of g++ for Unix? |
| |
| First, you may already have it if you have gcc for your platform; |
| g++ and gcc are combined now (as of gcc version 2.0). |
| @cindex GNU gcc, version |
| @cindex GNU g++ and gcc |
| |
| You can get g++ from a friend who has a copy, by anonymous FTP or |
| UUCP, or by ordering a tape or CD-ROM from the Free Software |
| Foundation. |
| @cindex g++, ordering |
| @cindex g++, getting a copy |
| |
| The Free Software Foundation is a nonprofit organization that |
| distributes software and manuals to raise funds for more GNU |
| development. Getting your copy from the FSF contributes directly to |
| paying staff to develop GNU software. CD-ROMs cost $400 if an |
| organization is buying, or $100 if an individual is buying. Tapes |
| cost around $200 depending on media type. I recommend asking for |
| version 2, not version 1, of g++. |
| @cindex FSF [Free Software Foundation] |
| @cindex GNU [GNU's not unix] |
| |
| For more information about ordering from the FSF, contact |
| gnu@@prep.ai.mit.edu, phone (617) 542-5942 or anonymous ftp file |
| @file{ftp://prep.ai.mit.edu/pub/gnu/GNUinfo/ORDERS} (you can |
| also use one of the sites listed below if you can't get into ``prep''). |
| |
| @cindex FSF, contact <gnu@@prep.ai.mit.edu> |
| |
| Here is a list of anonymous FTP archive sites for GNU software. |
| If no directory is given, look in @file{/pub/gnu}. |
| |
| @cindex GNUware, anonymous FTP sites |
| |
| @example |
| ASIA: ftp.cs.titech.ac.jp, tron.um.u-tokyo.ac.jp:/pub/GNU/prep |
| cair-archive.kaist.ac.kr, ftp.nectec.or.th:/pub/mirrors/gnu |
| |
| AUSTRALIA: archie.au:/gnu (archie.oz or archie.oz.au for ACSnet) |
| |
| AFRICA: ftp.sun.ac.za |
| |
| MIDDLE-EAST: ftp.technion.ac.il:/pub/unsupported/gnu |
| |
| EUROPE: irisa.irisa.fr, ftp.univ-lyon1.fr, |
| ftp.mcc.ac.uk, unix.hensa.ac.uk:/mirrors/uunet/systems/gnu, |
| src.doc.ic.ac.uk:/gnu, ftp.ieunet.ie, ftp.eunet.ch, |
| nic.switch.ch:/mirror/gnu, ftp.informatik.rwth-aachen.de, |
| ftp.informatik.tu-muenchen.de, ftp.win.tue.nl, ftp.nl.net, |
| ftp.etsimo.uniovi.es, ftp.funet.fi, ftp.denet.dk, |
| ftp.stacken.kth.se, isy.liu.se, ftp.luth.se:/pub/unix/gnu, |
| ftp.sunet.se, archive.eu.net |
| |
| SOUTH AMERICA: ftp.inf.utfsm.cl, ftp.unicamp.br |
| |
| WESTERN CANADA: ftp.cs.ubc.ca:/mirror2/gnu |
| |
| USA: wuarchive.wustl.edu:/systems/gnu, labrea.stanford.edu, |
| ftp.digex.net, ftp.kpc.com:/pub/mirror/gnu, f.ms.uky.edu:/pub3/gnu, |
| jaguar.utah.edu:/gnustuff, ftp.hawaii.edu:/mirrors/gnu, |
| uiarchive.cso.uiuc.edu, ftp.cs.columbia.edu:/archives/gnu/prep, |
| gatekeeper.dec.com:/pub/GNU, ftp.uu.net:/systems/gnu |
| @end example |
| |
| The ``official site'' is prep.ai.mit.edu, but your transfer will probably |
| go faster if you use one of the above machines. |
| |
| @cindex gzip |
| Most GNU utilities are compressed with ``gzip'', the GNU compression |
| utility. All GNU archive sites should have a copy of this program, |
| which you will need to uncompress the distributions. |
| |
| @cindex libg++ |
| Don't forget to retrieve libg++ as well! |
| |
| @node g++ for HP, g++ for Solaris 2.x, g++ for Unix, basics |
| @section Getting gcc/g++ for the HP Precision Architecture |
| |
| @cindex HP Precision Architecture |
| @cindex Hewlett-Packard |
| @cindex GNU GAS |
| @cindex GNU gdb |
| |
| If you use the HP Precision Architecture (HP-9000/7xx and HP-9000/8xx) |
| and you want to use debugging, you'll need to use the GNU assembler, GAS |
| (version 2.3 or later). If you build from source, you must tell the |
| configure program that you are using GAS or you won't get debugging |
| support. A non-standard debug format is used, since until recently HP |
| considered their debug format a trade secret. Thanks to the work of |
| lots of good folks both inside and outside HP, the company has seen the |
| error of its ways and has now released the required information. The |
| team at the University of Utah that did the gcc port now has code that |
| understands the native HP format. |
| |
| There are binaries for GNU tools in |
| @file{ftp://jaguar.cs.utah.edu/dist/}, |
| but these are older versions. |
| |
| Jeff Law has left the University of Utah, so the Utah prebuilt |
| binaries may be discontinued. |
| |
| @node g++ for Solaris 2.x, g++ for other platforms, g++ for HP, basics |
| @section Getting gcc/g++ binaries for Solaris 2.x |
| |
| ``Sun took the C compiler out of Solaris 2.x. Am I stuck?'' |
| |
| @cindex Solaris |
| @cindex gcc/g++ binaries for Solaris |
| |
| You'll need to get prebuilt binaries from someone. |
| |
| It used to be that you could get GCC binaries from prep.ai.mit.edu; |
| these are no longer there. |
| |
| @cindex Solaris pkgadd utility |
| The WWW site @file{http://smc.vnet.net/solaris_2.5.html} |
| contains various |
| GNU and freeware programs for Solaris2.5 running on the sparc. These are |
| packaged to enable easy installation using the Solaris ``pkgadd'' utility. |
| These include GNU emacs, gcc, gdb, perl, and others. These versions |
| are more recent than the binaries at ``prep'' (gcc 2.7.2 and libg++ |
| 2.7.1 are there). |
| |
| @node g++ for other platforms, 1.x vs 2.x versions, g++ for Solaris 2.x, basics |
| @section How do I get a copy of g++ for (some other platform)? |
| |
| @cindex Windows NT support |
| As of gcc-2.7.x, there is Windows NT support in gcc. Some special |
| utilities are required. See the INSTALL file from the distribution. |
| If you're interested in GNU tools on Windows NT, see |
| @file{http://www.cygnus.com/misc/gnu-win32/} on the WWW, or the |
| anonymous FTP directory |
| @file{ftp://ftp.cygnus.com/pub/gnu-win32/}. |
| |
| @cindex VMS support |
| @cindex VAX |
| @cindex VMS, g++/libg++ precompiled |
| |
| The standard gcc/g++ distribution includes VMS support for the Vax. |
| Since the FSF people don't use VMS, it's likely to be somewhat less |
| solid than the Unix version. Precompiled copies of g++ and libg++ in |
| VMS-installable form for the Vax are available by FTP from |
| @file{ftp://mango.rsmas.miami.edu/pub/VMS-gcc/}. |
| |
| @cindex OpenVMS/Alpha |
| Klaus Kaempf (kkaempf@@progis.de) |
| has done a port to OpenVMS for the Alpha; this is not yet a |
| part of the official gcc/g++. |
| The port includes g++ and all libraries from the libg++ distribution. See |
| @file{http://www.progis.de} for more details. |
| |
| @cindex MS-DOS support |
| @cindex Delorie's gcc/g++ |
| @cindex DJGPP |
| @cindex EMX |
| There are two different versions of gcc/g++ for MS-DOS: EMX and DJGPP. |
| EMX also works for OS/2 and is described later. |
| DJGPP is DJ Delorie's port. It can be found on many FTP archive |
| sites; try |
| @file{ftp://ftp.coast.net/SimTel/vendors/djgpp/} |
| or, for a complete list, see |
| @file{http://www.delorie.com/djgpp/getting.html}. |
| |
| |
| The latest version of DJGPP is 2.00. See |
| @file{http://www.delorie.com/djgpp/v2/} for information on this version. |
| |
| FSF sells floppies with DJGPP on them; see above for ordering software |
| from the FSF. |
| |
| DJGPP has its own newsgroup: @file{comp.os.msdos.djgpp}. |
| |
| @cindex Amiga support |
| Development and porting efforts for GNU tools, including gcc/g++, for |
| the Amiga are maintained by an initiative named ADE (Amiga Developers |
| Environment. More information about ADE is available at |
| @file{http://www.ninemoons.com/}. |
| |
| For more information on Amiga ports of gcc/g++, retrieve the file |
| @file{ftp://prep.ai.mit.edu/pub/gnu/MicrosPorts/Amiga}. |
| |
| @cindex Atari ST support |
| A port of gcc to the Atari ST can be found at @* |
| @file{ftp://atari.archive.umich.edu/atari/Gnustuff/Tos} |
| along with many |
| other GNU programs. This version is usually the same as the latest FSF |
| release. See the ``Software FAQ'' for the Usenet group |
| @file{comp.sys.atari.st} for more information. |
| |
| @cindex EMX port |
| @cindex OS/2 support |
| |
| EMX is a port of gcc to OS/2; it can also be used on MS-DOS. In addition to |
| the compiler port, the EMX port's C library attempts to provide a |
| Unix-like environment. For more information ask around on |
| @file{comp.os.os2.programmer.porting}. Version 0.9c, based on gcc-2.7.2.1, |
| was released in |
| November 1996. It is available by FTP and the WWW from, among other |
| places |
| |
| @example |
| @file{http://www.os2ss.com/unix/emx09c/} |
| @file{ftp://ftp.cdrom.com/pub/os2/emx09c/} (US) |
| @file{ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/} (Germany) |
| @end example |
| |
| Eberhard Mattes did the EMX port. His address is |
| mattes@@azu.informatik.uni-stuttgart.de. |
| Read the FAQ file included with the distribution before harrassing the author. |
| |
| @cindex Apple support |
| @cindex Macintosh support |
| |
| I'm looking for more information on gcc/g++ support on the Apple |
| Macintosh. Until recently, this FAQ did not provide such information, |
| but FSF is no longer boycotting Apple as the League for Programming |
| Freedom boycott has been dropped. |
| |
| Versions 1.37.1 and 2.3.3 of gcc were ported by Stan Shebs and are available |
| at @* |
| @file{ftp://ftp.cygnus.com/pub/mac} |
| |
| They are both interfaced to MPW. |
| Stan is working on a version using the current (post-2.7) sources, contact |
| him directly (shebs@@cygnus.com) for more information. |
| |
| @node 1.x vs 2.x versions, , g++ for other platforms, basics |
| @section But I can only find g++-1.42! |
| |
| ``I keep hearing people talking about g++ 2.7.2 (or some other number |
| starting with 2), but the latest version I can find is g++ 1.42. |
| Where is it?'' |
| |
| @cindex Objective-C |
| @cindex g++, version number |
| As of gcc 2.0, C, C++, and Objective-C as well are all combined into a |
| single distribution called gcc. If you get gcc you already have g++. The |
| standard installation procedure for any gcc version 2 compiler will |
| install the C++ compiler as well. |
| |
| One could argue that we shouldn't even refer to "g++-2.x.y" but it's a |
| convention. It means ``the C++ compiler included with gcc-2.x.y.'' |
| |
| @node installation, evolution, basics, Top |
| @chapter Installation Issues and Problems |
| |
| @menu |
| * gcc-2 + g++-1:: |
| * what else do I need?:: |
| * use GNU linker?:: |
| * Use GNU assembler?:: |
| * shared libraries:: |
| * repository:: |
| * repo bugs:: |
| * Use GNU C library?:: |
| * Global constructor problems:: |
| * Strange assembler errors:: |
| * Other problems building libg++:: |
| * More size_t problems:: |
| * Rebuild libg++?:: |
| * co-existing versions:: |
| * Installing on Linux:: |
| * Linux Slackware 3.0:: |
| @end menu |
| |
| @node gcc-2 + g++-1, what else do I need?, installation, installation |
| @section I can't build g++ 1.x.y with gcc-2.x.y! |
| |
| ``I obtained gcc-2.x.y and g++ 1.x.y and I'm trying to build it, but |
| I'm having major problems. What's going on?'' |
| |
| @cindex g++, building |
| If you wish to build g++-1.42, you must obtain gcc-1.42 first. The |
| installation instructions for g++ version 1 leave a lot to be desired, |
| unfortunately, and I would recommend that, unless you have a special |
| reason for needing the 1.x compiler, that C++ users use the latest |
| g++-2.x version, as it |
| is the version that is being actively maintained. |
| |
| @cindex g++, template support |
| @cindex Templates |
| @cindex ANSI draft standard |
| There is no template support in g++-1.x, and it is generally much further |
| away from the ANSI draft standard than g++-2.x is. |
| |
| @node what else do I need?, use GNU linker?, gcc-2 + g++-1, installation |
| @section OK, I've obtained gcc; what else do I need? |
| |
| @cindex libg++ |
| First off, you'll want libg++ as you can do almost nothing without it |
| (unless you replace it with some other class library). |
| |
| @cindex GNU GAS |
| @cindex GNU GAS [assembler] |
| Second, depending on your platform, you may need "GAS", the GNU assembler, |
| or the GNU linker (see next question). |
| |
| @cindex GNU gdb |
| Finally, while it is not required, you'll almost certainly want the GNU |
| debugger, gdb. The latest version is |
| 4.16, released April 22, 1996. |
| Other debuggers (like dbx, for example) will normally not be able to |
| understand at least some of the debug information produced by g++. |
| |
| @node use GNU linker?, Use GNU assembler?, what else do I need?, installation |
| @section Should I use the GNU linker, or should I use "collect"? |
| |
| @cindex Linker |
| @cindex System VR3, linker |
| @cindex System VR4, linker |
| First off, for novices: special measures must be taken with C++ to arrange |
| for the calling of constructors for global or static objects before the |
| execution of your program, and for the calling of destructors at the end. |
| (Exception: System VR3 and System VR4 linkers, Linux/ELF, and some other |
| systems support user-defined |
| segments; g++ on these systems requires neither the GNU linker nor |
| collect. So if you have such a system, the answer is that you don't |
| need either one, though using GNU ld does have some advantages over |
| the native linker in some cases). |
| |
| @cindex AT&T cfront |
| @cindex Cfront-end |
| @cindex collect program |
| @cindex GNU linker |
| @cindex GNU binutils |
| If you have experience with AT&T's "cfront", this function is performed |
| there by programs named "patch" or "munch". With GNU C++, it is performed |
| either by the GNU linker or by a program known as "collect". The collect |
| program is part of the gcc-2.x distribution; you can obtain the GNU linker |
| separately as part of the "binutils" package. The latest version of |
| binutils is 2.7, released July 10, 1996; 2.6 is in common use and works |
| well. |
| |
| (To be technical, it's "collect2"; there were originally several |
| alternative versions of collect, and this is the one that survived). |
| |
| There are advantages and disadvantages to either choice. |
| |
| Advantages of the GNU linker: |
| @cindex GNU linker, advantages |
| @cindex GNU ld |
| @cindex ld [GNU linker] |
| |
| It's faster than using collect -- collect basically runs the standard Unix |
| linker on your program twice, inserting some extra code after the first |
| pass to call the constructors. This is a sizable time penalty for large |
| programs. The GNU linker does not require this extra pass. |
| |
| GNU ld reports undefined symbols using their true names, not the mangled |
| names (but as of 2.7.0 so does collect). |
| |
| If there are undefined symbols, GNU ld reports which object file(s) refer to |
| the undefined symbol(s). On some OSes (e.g. SunOS, Solaris) the native |
| linker does not do this, so you have to track down who's referring to |
| the missing symbols yourself. |
| |
| As of binutils version 2.2, on systems that use the so-called "a.out" |
| debug format (e.g. Suns running SunOS 4.x), the GNU linker compresses |
| the debug symbol table considerably. The 2.7 version adds some symbol |
| table compression for ELF and Solaris targets. |
| |
| @cindex collect linker, advantages |
| Advantages of collect: |
| |
| @cindex Shared libraries |
| If your native linker supports shared libraries, you can use shared |
| libraries with collect. This used to be a strong reason @emph{not} |
| to use the GNU linker, but recent versions of GNU ld support linking |
| with shared libraries on many platforms, and creating shared libraries |
| on a few (such as Intel x86 systems that use ELF object format as well |
| as SunOS and Solaris). |
| |
| @xref{shared libraries} |
| |
| @cindex GNU linker, porting |
| The GNU linker has not been ported to as many platforms as g++ has, so you |
| may be forced to use collect. |
| |
| If you use collect, you don't need to get something extra and figure out |
| how to install it; the standard gcc installation procedure will do it for you. |
| |
| I used to say at this point that I don't see a clear win for either |
| linking alternative, but with all the improvements in the GNU linker |
| I think that it is now the better choice. Take your pick. |
| |
| If you run Linux, the only available linker is the GNU linker. |
| |
| @node Use GNU assembler?, shared libraries, use GNU linker?, installation |
| @section Should I use the GNU assembler, or my vendor's assembler? |
| |
| @cindex Assembler |
| @cindex GNU GAS |
| This depends on your platform and your decision about the GNU linker. For |
| most platforms, you'll need to use GAS if you use the GNU linker. For |
| some platforms, you have no choice; check the gcc installation notes to |
| see whether you must use GAS. But you can usually use the vendor's |
| assembler if you don't use the GNU linker. |
| |
| The GNU assembler assembles faster than many native assemblers; however, |
| on many platforms it cannot support the local debugging format. |
| |
| It used to be that the GNU assembler couldn't handle |
| position-independent code on SunOS. This is no longer true if you |
| have version 2.6 or newer. |
| |
| On HPUX or IRIX, you must use GAS (and configure gcc with the |
| @code{--with-gnu-as} option) to debug your programs. GAS is |
| strongly recommended particularly on the HP platform because of |
| limitations in the HP assembler. |
| |
| The GNU assembler has been merged with the binutils |
| distribution, so the GNU assembler and linker are now together in |
| this package (as of binutils version 2.5.1). |
| |
| On Linux the assembler is the GNU assembler. |
| |
| @node shared libraries, repository, Use GNU assembler?, installation |
| @section How do I build shared libraries with g++? |
| |
| For gcc-2.7.0 and later, building C++ shared libraries should work fine |
| on supported platforms (HPUX 9+, IRIX 5+, DEC UNIX (formerly OSF/1), |
| SGI/IRIX, AIX, SunOS 4, Linux/ELF and all targets using SVR4-style ELF shared |
| libraries). There are two separate issues: building libg++ as a shared |
| library, and making your own shared libraries. For libg++ it is simply |
| a matter of giving the @code{--enable-shared} option to the configure |
| program. When compiling your own code for shared libraries you |
| generally |
| must use the @code{-fPIC} flag to get position-independent code. |
| |
| @cindex -shared flag of gcc |
| |
| If your shared library contains global or static objects with |
| constructors, then make sure to use @code{gcc -shared}, not |
| @code{ld}, to create the shared library. This will make sure |
| that any processor-specific magic needed to execute the constructors |
| is included. |
| |
| In theory, constructors for objects in your shared library should be |
| called when the library is opened (by dlopen or equivalent). This |
| does not work on some platforms (e.g. SunOS4; it does work on Solaris |
| and ELF systems such as Linux): on the broken platforms, the |
| constructors are not called correctly. |
| |
| David Nilsen has suggested the following workaround: |
| |
| The thing to realize is that if you link your dynamic module with the |
| @code{-shared} flag, the collect program nicely groups all the static |
| ctors/dtors for you into a list and sets up a function that will call |
| them (Note: this means that this trick won't work if you use the GNU |
| linker without collect (@pxref{use GNU linker?}). |
| |
| The magic is knowing these function names. Currently, they're called: |
| |
| @example |
| _GLOBAL__DI <-- calls all module constructors |
| _GLOBAL__DD <-- calls all module destructors |
| @end example |
| |
| [ possibly the leading underscore will differ between platforms: jbuck ] |
| |
| Therefore, if you make a wrapper around dlopen that looks up the |
| symbol @code{_GLOBAL__DI} (or @code{__GLOBAL__DI} on SunOS4 machines), and |
| calls it, you'll simulate getting the constructors called. |
| |
| You also need to set up the destructors to be called as well, so you |
| need to put a wrapper around dlclose, which will call the |
| @code{_GLOBAL__DD} function in the module when/if it's unloaded. |
| |
| Lastly, to get things 100% correct, you need to set up the destructors |
| to also be called if the module is not unloaded, but the main program |
| exits. I do this by registering a single function with @code{atexit()} that |
| calls all the destructors left in dynamically loaded modules. |
| |
| @cindex Shared version of libg++ |
| Check the file @file{README.SHLIB} from the libg++ distribution for more |
| about making and using shared libraries. |
| |
| @cindex Shared libraries with HP |
| |
| A patch is needed to build shared versions of version 2.7.2 of libg++ |
| and libstdc++ on the HP-PA architecture. You can find the patch at |
| @file{ftp://ftp.cygnus.com/pub/g++/libg++-2.7.2-hppa-gcc-fix}. |
| |
| @node repository, repo bugs, shared libraries, installation |
| @section How do I use the new repository code? |
| |
| @cindex repo patch |
| Because there is some disagreement about the details of the template |
| repository mechanism, you'll need to obtain a patch from Cygnus Support |
| to enable the 2.7.2 repository code. You can obtain the patch by |
| anonymous FTP: @file{ftp://ftp.cygnus.com/pub/g++/gcc-2.7.2-repo.gz}. |
| |
| There are patches for 2.7.0 and 2.7.1 in the same directory, though |
| if you're going to rebuild the compiler you should use the latest one. |
| |
| @cindex repo patch for BSD |
| If you're running NetBSD or BSDI, the Cygnus repo patch is not quite |
| correct. Tim Liddelow has made an alternate version available at |
| @file{ftp://ftp.cst.com.au/pub/gcc-2.7.2-repo-bsd.gz}. |
| |
| After you've applied the patch, the @code{-frepo} flag will enable the |
| repository mechanism. The flag works much like the existing |
| @code{-fno-implicit-templates} flag, except that auxiliary files, with |
| an @file{.rpo} extension, are built that specify what template |
| expansions are needed. At link time, the (patched) collect program |
| detects missing templates and recompiles some of the object files |
| so that the required templates are expanded. |
| |
| Note that the mechanism differs from that of cfront in that template |
| definitions still must be visible at the point where they are to be |
| expanded. No assumption is made that @file{foo.C} contains template |
| definitions corresponding to template declarations in @file{foo.h}. |
| |
| @cindex closure with repo |
| @cindex template closure |
| Jason Merrill writes: ``To perform closure on a set of objects, just try |
| to link them together. It will fail, but as a side effect all needed |
| instances will be generated in the objects.'' |
| |
| @node repo bugs, Use GNU C library?, repository, installation |
| @section Known bugs and problems with the repo patch |
| |
| ``The @code{-frepo} won't expand templated friend functions!'' |
| |
| This is a known bug; currently you'll have to explicitly instantiate |
| friend functions when using @code{-frepo} due to this bug (in 2.7.0 |
| through 2.7.2 at least). |
| |
| With earlier versions of the repo patch, there was a bug that happens |
| when you have given a quoted command line switch, something like |
| |
| @example |
| -D'MESSAGE="hello there"' |
| @end example |
| |
| The repo code tries to recompile files using the same flags you |
| originally specified, but doesn't quote arguments that need quoting, |
| resulting in failures in some cases. This is no longer a problem |
| with the 2.7.2 patch. |
| |
| @node Use GNU C library?, Global constructor problems, repo bugs, installation |
| @section Should I use the GNU C library? |
| |
| @cindex GNU C library |
| @cindex libg++ |
| At this point in time, no (unless you are running Linux or the GNU Hurd |
| system). The GNU C library is still very young, and |
| libg++ still conflicts with it in some places. Use your native C library |
| unless you know a lot about the gory details of libg++ and gnu-libc. This |
| will probably change in the future. |
| |
| @node Global constructor problems, Strange assembler errors, Use GNU C library?, installation |
| @section Global constructors aren't being called |
| |
| @cindex global constructors |
| ``I've installed gcc and it almost works, but constructors and |
| destructors for global objects and objects at file scope aren't being |
| called. What did I do wrong?'' |
| |
| @cindex collect program |
| It appears that you are running on a platform that requires you to |
| install either "collect2" or the GNU linker, and you have done neither. |
| For more information, see the section discussing the GNU linker |
| (@pxref{use GNU linker?}). |
| |
| @cindex constructor problems on Solaris |
| @cindex Solaris, constructor problems |
| On Solaris 2.x, you shouldn't need a collect program and GNU ld doesn't run. |
| If your global constructors aren't being called, you may need to install |
| a patch, available from Sun, to fix your linker. The number of the |
| ``jumbo patch'' that applies is 101409-03. Thanks to Russell Street |
| (r.street@@auckland.ac.nz) for this info. |
| |
| @cindex IRIX, installing collect |
| It appears that on IRIX, the collect2 program is not being installed |
| by default during the installation process, though it is required; |
| you can install it manually by executing |
| |
| @example |
| make install-collect2 |
| @end example |
| |
| from the gcc source directory after installing the compiler. (I'm |
| not certain for which versions of gcc this problem occurs, and whether |
| it is still present). |
| |
| @node Strange assembler errors, Other problems building libg++, Global constructor problems, installation |
| @section Strange assembler errors when linking C++ programs |
| |
| ``I've installed gcc and it seemed to go OK, but when I attempt to link |
| any C++ program, I'm getting strange errors from the assembler! How |
| can that be?'' |
| |
| The messages in question might look something like |
| |
| @example |
| as: "/usr/tmp/cca14605.s", line 8: error: statement syntax |
| as: "/usr/tmp/cca14605.s", line 14: error: statement syntax |
| @end example |
| |
| (on a Sun, different on other platforms). The important thing is that |
| the errors come out at the link step, @emph{not} when a C++ file is |
| being compiled. |
| |
| @cindex nm program |
| @cindex GNU nm program |
| Here's what's going on: the collect2 program uses the Unix ``nm'' |
| program to obtain a list of symbols for the global constructors and |
| destructors, and it builds a little assembly language module that |
| will permit them all to be called. If you're seeing this symptom, |
| you have an old version of GNU nm somewhere on your path. This old |
| version prints out symbol names in a format that the collect2 program |
| does not expect, so bad assembly code is generated. |
| |
| The solution is either to remove the old version of GNU nm from your |
| path (and that of everyone else who uses g++), or to install a newer |
| version (it is part of the GNU "binutils" package). Recent versions |
| of GNU nm do not have this problem. |
| |
| @node Other problems building libg++, More size_t problems, Strange assembler errors, installation |
| @section Other problems building libg++ |
| @cindex libg++ on Ultrix |
| @cindex libg++ on SunOS |
| |
| ``I am having trouble building libg++. Help!'' |
| |
| On some platforms (for example, Ultrix), you may see errors complaining |
| about being unable to open dummy.o. On other platforms (for example, |
| SunOS), you may see problems having to do with the type of size_t. |
| The fix for these problems is to make libg++ by saying "make CC=gcc". |
| According to Per Bothner, it should no longer be necessary to specify |
| "CC=gcc" for libg++-2.3.1 or later. |
| |
| ``I built and installed libg++, but g++ can't find it. Help!'' |
| |
| The string given to @file{configure} that identifies your system must |
| be the same when you install libg++ as it was when you installed gcc. |
| Also, if you used the @code{--prefix} option to install gcc somewhere |
| other than @file{/usr/local}, you must use the same value for |
| @code{--prefix} when installing libg++, or else g++ will not be able |
| to find libg++. |
| |
| @cindex patch for libg++-2.6.2 |
| |
| The toplevel Makefile in the libg++ 2.6.2 distribution is broken, which |
| along with a bug in g++ 2.6.3 causes problems linking programs that use the |
| libstdc++ complex classes. A patch for this is available from |
| @file{ftp://ftp.cygnus.com//pub/g++/libg++-2.6.2-fix.gz}. |
| |
| @node More size_t problems, Rebuild libg++?, Other problems building libg++, installation |
| @section But I'm @emph{still} having problems with @code{size_t}! |
| |
| @cindex Type of size_t |
| ``I did all that, and I'm @emph{still} having problems with disagreeing |
| definitions of size_t, SIZE_TYPE, and the type of functions like |
| @code{strlen}.'' |
| |
| @cindex _G_config.h |
| The problem may be that you have an old version of @file{_G_config.h} |
| lying around. As of libg++ version 2.4, @file{_G_config.h}, since it is |
| platform-specific, is inserted into a different directory; most include |
| files are in @file{$prefix/lib/g++-include}, but this file now lives in |
| @file{$prefix/$arch/include}. If, after upgrading your libg++, you find that |
| there is an old copy of @file{_G_config.h} left around, remove it, |
| otherwise g++ will find the old one first. |
| |
| @node Rebuild libg++?, co-existing versions, More size_t problems, installation |
| @section Do I need to rebuild libg++ to go with my new g++? |
| |
| ``After I upgraded g++ to the latest version, I'm seeing undefined |
| symbols.'' |
| |
| or |
| |
| ``If I upgrade to a new version of g++, do I need to reinstall libg++?'' |
| |
| @cindex Incompatibilities between g++ versions |
| |
| As a rule, the first two digits of your g++ and libg++ should be the |
| same. Normally when you do an upgrade in the ``minor version number'' |
| (2.5.7 to 2.5.8, say) there isn't a need to rebuild libg++, but there |
| have been a couple of exceptions in the past. |
| |
| @node co-existing versions, Installing on Linux, Rebuild libg++?, installation |
| @section I want several versions of g++ and libg++ to co-exist. |
| |
| I recommend against using the @code{-V} flag to make multiple versions |
| of gcc/g++ co-exist, unless they are different minor releases that can use |
| the same compiled version of libg++. The reason is that all these |
| versions will try to use the same libg++ version, which usually will |
| not work. |
| |
| Instead, use the @code{--prefix} flag when configuring gcc. Use a |
| different value of @code{--prefix} for each gcc version. Use the |
| same value of @code{--prefix} when configuring libg++. You can then |
| have any number of co-existing gcc/libg++ pairs. Symbolic links can |
| be used so that users don't need to put all these different directories |
| on their paths. |
| |
| One possible system to use is to set @code{--prefix} to |
| @file{/usr/local/gcc-2.x.y} for version 2.x.y of gcc, and to link |
| whichever version of gcc you wish to be the default into |
| @file{/usr/local/bin/gcc} and @file{/usr/local/bin/g++}. |
| |
| @node Installing on Linux, Linux Slackware 3.0, co-existing versions, installation |
| @section Trouble installing g++ and libg++ on Linux |
| |
| ``I've downloaded the latest g++ and libg++ and I'm trying to install |
| them on Linux, and I'm having lots of problems.'' |
| |
| @cindex Linux |
| FSF releases of libg++ won't install on Linux unchanged, since Linux |
| uses are part of the libio library from libg++ for its standard C |
| library, only this is changed in a way that it clashes with libg++. |
| This means that you'll need a patched version of libg++ for it to |
| work. |
| |
| If you want to upgrade to a new gcc/libg++ combination, the easiest |
| thing to do is to grab the prebuilt versions of gcc and libg++ for Linux |
| from @file{ftp://tsx-11.mit.edu/pub/linux/packages/GCC}. Follow the |
| directions carefully. If you want to build from source, you'll need |
| a patch for libg++; the Linux developers have named the patched libg++ |
| version libg++-2.7.1.3 and there is a patch file in the above-named |
| directory. |
| |
| See @file{http://sunsite.unc.edu/LDP/HOWTO/GCC-HOWTO.html}, |
| the Linux GCC HOWTO, for more on gcc/g++ and Linux. |
| |
| Linux is in the process of switching over to the GNU C library, version |
| 2, which will become Linux libc version 6. Once this process is |
| complete, there's a good chance that the installation process on Linux |
| will be smoother, but only experts should try making this new library |
| work at this point. |
| |
| @node Linux Slackware 3.0, , Installing on Linux, installation |
| @section Problems with g++ on Linux Slackware 3.0 |
| |
| @cindex Slackware |
| @cindex Linux Slackware |
| ``When I try to compile the traditional Hello, world program on Linux, |
| the compiler can't find @file{iostream.h}. What's the deal?'' |
| |
| You probably have the Slackware 3.0 release. There's an error in the |
| setup. It's easy to fix, though; log in as root, and make a symbolic |
| link: |
| |
| @example |
| ln -s /usr/lib/g++-include /usr/include/g++ |
| @end example |
| |
| @node evolution, User Problems, installation, Top |
| @chapter The Evolution of g++ |
| |
| This chapter discusses the evolution of g++ and describes what can be expected |
| in the future. |
| |
| @menu |
| * version 2.7.x:: What's changed in 2.7.x from earlier versions |
| * libstdc++:: The GNU C++ standard library |
| * new work:: What's been done since 2.7.x |
| * egcs:: The Experimental GNU Compiler System |
| * When?:: When can I get all this new stuff? |
| @end menu |
| |
| @node version 2.7.x, libstdc++, evolution, evolution |
| @section What's new in version 2.7.x of gcc/g++ |
| |
| The current version of gcc/g++ is 2.7.2.2, released February 10, 1997. |
| The only change between 2.7.2.1 and 2.7.2.2 is that support was added |
| for using the GNU C library, version 2, on Linux; users not interested |
| in that functionality have no reason to upgrade. |
| The previous version of gcc/g++ is 2.7.2.1, released August 14, 1996. |
| The current version of libg++ is 2.7.2, released July 4, 1996. |
| |
| Note that gcc 2.7.2.1 just consists of several small patches to |
| gcc-2.7.2. The release is mainly |
| intended to fix platform-specific bugs and does not affect the C++ |
| ``front end'' of the compiler (the part that parses your C++ code). |
| |
| The 2.7.x releases represent a great deal of work on the part of the g++ |
| maintainers to fix outstanding bugs and move the compiler closer to the |
| current ANSI/ISO standards committee's working paper, including |
| supporting many of the new features that have been added to the |
| language. I recommend that everyone read the NEWS file contained in the |
| distribution (and that system administrators make the file available to |
| their users). I've borrowed liberally from this file here. |
| |
| @cindex C++ working paper |
| If any features seem unfamiliar, you will probably want to |
| look at the recently-released public review copy of the C++ Working |
| Paper. A new draft, dated 2 December 1996, has been released for |
| public comment. You can find it on the web at |
| @file{http://www.cygnus.com/misc/wp/} or |
| @file{http://www.maths.warwick.ac.uk/c++/pub/wp/html/cd2/}. |
| See |
| @file{http://www.setech.com/x3.html} |
| or |
| @file{http://www.maths.warwick.ac.uk/c++/pub/} to download the |
| document in PostScript, PDF (Adobe Acrobat), HTML, or ASCII |
| form. |
| |
| Here are the main points: |
| |
| @itemize @bullet |
| @item |
| @cindex for scope |
| As described above, the scope of variables declared in the |
| initialization part of a for statement has been changed; such variables |
| are now visible only in the loop body. Use @code{-fno-for-scope} to get |
| the old behavior. You'll need this flag to build groff version 1.09, |
| Ptolemy, and many other free software packages. |
| |
| @item |
| @cindex vtable duplication |
| Code that does not use #pragma interface/implementation will most |
| likely shrink dramatically, as g++ now only emits the vtable for a |
| class in the translation unit where its first non-inline, non-abstract |
| virtual function is defined. |
| |
| @item |
| @cindex automatic template instantiation |
| Support for automatic template instantiation has @emph{not} been enabled |
| in the official distribution, due to a disagreement over design philosophies. |
| But you can get a patch from Cygnus to turn it on; retrieve the patch |
| from @file{ftp://ftp.cygnus.com/pub/g++/gcc-2.7.2-repo.gz} to patch |
| gcc-2.7.2 (there are also patches for earlier gcc versions). |
| |
| @item |
| @cindex exception handling, 2.7.0 |
| |
| @xref{exceptions} |
| |
| @item |
| @cindex run-time type identification |
| Support for Run-Time Type Identification has been added with @code{-frtti}. |
| This support is still in alpha; one major restriction is that any file |
| compiled with @code{-frtti} must include @code{<typeinfo>} (@emph{not} |
| @code{typeinfo.h} as the NEWS file says). |
| Also, all C++ code you link with (including libg++) has to be built with |
| @code{-frtti}, so it's still tricky to use. |
| |
| @item |
| @cindex compiler-generated operators |
| Synthesis of compiler-generated constructors, destructors and |
| assignment operators is now deferred until the functions are used. |
| |
| @item |
| @cindex assignment in conditional expressions |
| The parsing of expressions such as @code{a ? b : c = 1} |
| has changed from |
| @code{(a ? b : c) = 1} to @code{a ? b : (c = 1)}. This is a new C/C++ |
| incompatibility brought to you by the ANSI/ISO standards committee. |
| |
| @item |
| @cindex new operator keywords |
| The operator keywords and, and_eq, bitand, bitor, compl, not, not_eq, |
| or, or_eq, xor and xor_eq are now supported. Use @code{-ansi} or |
| @code{-foperator-names} to enable them. |
| |
| @item |
| @cindex explicit keyword |
| The @code{explicit} keyword is now supported. @code{explicit} is used to mark |
| constructors and type conversion operators that should not be used |
| implicitly. |
| |
| @item |
| @cindex user-defined type conversion |
| Handling of user-defined type conversion has been improved. |
| |
| @item |
| @cindex explicit template instantiation |
| Explicit instantiation of template methods is now supported. Also, |
| @code{inline template class foo<int>;} |
| can be used to emit only the vtable |
| for a template class. |
| |
| @item |
| @cindex -fcheck-new |
| With -fcheck-new, g++ will check the return value of all calls to |
| operator new, and not attempt to modify a returned null pointer. |
| |
| @item |
| collect2 now demangles linker output, and c++filt has become part of |
| the gcc distribution. |
| |
| @item |
| Improvements to template instantiation: only members actually used |
| are instantiated. (Actually this is not quite true: some inline |
| templates that are not successfully inlined may be expanded even |
| though they are not needed). |
| |
| @end itemize |
| |
| @node libstdc++, new work, version 2.7.x, evolution |
| @section The GNU Standard C++ Library |
| |
| The GNU Standard C++ Library (also called the ``GNU ANSI C++ Library'' |
| in places in the code) is not libg++, though it is included in the |
| libg++ distribution. Rather, it contains classes and functions |
| required by the ANSI/ISO standard. The copyright conditions are the |
| same as those for for the iostreams classes; the LGPL is not used |
| (@pxref{legalities}). |
| |
| This library, libstdc++, is in the libg++ distribution in versions 2.6.2 |
| and later. It requires at least gcc 2.6.3 to build the libg++-2.6.2 |
| version; use at least gcc 2.7.0 to build the libg++ 2.7.0 version. It |
| contains a hacked-up version of HP's implementation of the Standard |
| Template Library (@pxref{Standard Template Library}). I've |
| successfully used this Standard Template Library version to build |
| a number of the demos you'll see on various web pages. |
| |
| As of version 2.7.0, the streams classes are now in libstdc++ instead of |
| libg++, and libiostream is being phased out (don't use it). The g++ |
| program searches this library. |
| |
| The maintainers of libg++ have de-emphasized work on the older libg++ classes |
| in favor of enhancing libstdc++ to cover the full language, so while libg++ |
| will always be available, enhancements to it should not be expected. |
| |
| @node new work, egcs, libstdc++, evolution |
| @section What can we expect in future gcc releases? |
| |
| A great deal of work has gone into enhancements to the C++ front end, as well |
| as to other aspects of the compiler. |
| |
| The next major release(s) of gcc/g++ can be expected to have the following |
| features: |
| |
| @itemize @bullet |
| @cindex new template implementation |
| @item |
| A completely new template implementation, much closer to the draft |
| standard. Limitations in 2.7.2.x concerning inlining template functions |
| will be eliminated. Static template data members, template class member |
| functions, partial specification, and default template arguments will be |
| supported. An instantiation method resembling that used in Borland C++ |
| (instantiating functions possibly in multiple .o files and using weak |
| symbols to link correctly) will be provided, in addition to other |
| options. The SGI version of STL will be shipped with libstdc++ and will |
| compile unchanged. |
| |
| @item |
| @cindex new exception implementation |
| Exception handling has been re-worked; exceptions will work together |
| with optimization. |
| Actually, there are two separate implementations: one based on setjmp/longjmp |
| and designed to be highly portable, and one designed to be more efficient but |
| requiring more processor-specific support (getting exceptions right has proven |
| to be extremely difficult and has been the chief obstacle to getting a new |
| release out). |
| |
| @item |
| @cindex RTTI |
| RTTI has been re-done to work correctly and is on by default. |
| |
| @item |
| @cindex overloading |
| Overloading has been re-worked to conform to the latest draft of the |
| standard. |
| @end itemize |
| |
| Features that are still missing include namespaces and templates as |
| template arguments. |
| |
| @node egcs, When?, new work, evolution |
| @section What's this I hear about egcs? |
| |
| The egcs effort is a new effort to merge several threads of gcc |
| development and to provide a faster development process. |
| For more information see @file{http://www.cygnus.com/egcs/}. |
| |
| @node When?, , egcs, evolution |
| @section OK, when can I get this stuff? |
| |
| The FSF has a policy of never announcing release dates in advance. |
| I'm sure this is frustrating to a lot of people, since it's taken |
| so long, and this frustration was one of the reasons the egcs effort |
| was created. An egcs release should be expected to occur in the |
| very near future. [ More on this next time ]. |
| |
| @node User Problems, legalities, evolution, Top |
| @chapter User Problems |
| |
| @menu |
| * missing virtual table:: |
| * for scope:: |
| * const constructor:: |
| * unused parameter warnings:: |
| * jump crosses initialization:: |
| * Demangler:: |
| * static data members:: |
| * internal compiler error:: |
| * bug reports:: |
| * porting to g++:: |
| * name mangling:: |
| * problems linking with other libraries:: |
| * documentation:: |
| * templates:: |
| * undefined templates:: |
| * redundant templates:: |
| * Standard Template Library:: |
| * STL and string:: |
| * exceptions:: |
| * namespaces:: |
| * agreement with standards:: |
| * compiling standard libraries:: |
| * debugging on SVR4 systems:: |
| * debugging problems on Solaris:: |
| * X11 conflicts with libg++:: |
| * assignment to streams:: |
| @end menu |
| |
| @node missing virtual table, for scope, User Problems, User Problems |
| @section Linker complains about missing virtual table |
| |
| ``I'm getting a message complaining about an undefined virtual table. Is |
| this a compiler bug?'' |
| |
| (On platforms that run neither collect nor the GNU linker, like Solaris, |
| you may see an odd undefined symbol like "_vt.3foo", where foo is a |
| class name). |
| |
| This is probably because you are missing a definition for the first |
| (non-inline) virtual function of the class. Since gcc-2.7.0, g++ uses |
| a trick borrowed from cfront: the .o file containing the definition for |
| the first non-inline virtual function for the class will also contain |
| the virtual function table. |
| |
| @node for scope, const constructor, missing virtual table, User Problems |
| @section gcc-2.7.0 breaks declarations in "for" statements! |
| |
| @cindex declarations in for statements |
| @cindex for statements: declarations |
| |
| gcc-2.7.0 implements the new ANSI/ISO rule on the scope of variables |
| declared in for loops. |
| |
| @example |
| for (int i = 1; i <= 10; i++) @{ |
| // do something here |
| @} |
| foo(i); |
| @end example |
| |
| In the above example, most existing C++ compilers would pass the |
| value 11 to the function @code{foo}. In gcc 2.7 and in the ANSI/ISO |
| working paper, the scope of @code{i} is only the for loop body, so |
| this is an error. So that old code can be compiled, the new gcc has |
| a flag @code{-fno-for-scope} that causes the old rule to be used. |
| @cindex -fno-for-scope |
| |
| As of 2.7.1, the compiler attempts to issue warnings about code that |
| has different meanings under the two sets of rules, but the code is |
| not perfect: the intent was that code that has valid, but different, |
| meanings under the ARM rules and the working paper rules would give |
| warnings but have the new behavior, and this doesn't seem to happen. |
| |
| The @code{-ffor-scope} flag under 2.7.1 and 2.7.2 gives the 2.7.0 behavior. |
| |
| @node const constructor, unused parameter warnings, for scope, User Problems |
| @section g++ seems to want a const constructor. What's that? |
| |
| gcc-2.7.1 introduced a bug that causes the compiler to ask for a |
| const constructor (there's no such thing in C++) in certain situations |
| where a const object appears in a template class. Most cases have been |
| fixed in gcc-2.7.2, but unfortunately not all. Still, if you're running |
| gcc-2.7.1 and have this problem, upgrade to 2.7.2; it is a vast improvement. |
| |
| @cindex ObjectSpace<STL> |
| |
| The default constructor for the template @code{pair} in ObjectSpace's |
| implementation of STL triggers the bug in one place, for gcc 2.7.2. If |
| you're using ObjectSpace<STL> and having this problem, simply |
| change the default constructor from |
| |
| @example |
| os_pair () : first (T1 ()), second (T2 ()) @{@} |
| @end example |
| |
| to just |
| |
| @example |
| os_pair () @{@} |
| @end example |
| |
| Once this is done, ObjectSpace<STL> works fairly well. |
| |
| @node unused parameter warnings, jump crosses initialization, const constructor, User Problems |
| @section How to silence ``unused parameter'' warnings |
| |
| @cindex -Wall |
| @cindex -Wunused |
| |
| ``When I use @code{-Wall} (or @code{-Wunused}), g++ warns about |
| unused parameters. But the parameters have to be there, for use |
| in derived class functions. How do I get g++ to stop complaining?'' |
| |
| The answer is to simply omit the names of the unused parameters when |
| defining the function. This makes clear, both to g++ and to readers |
| of your code, that the parameter is unused. For example: |
| |
| @example |
| int Foo::bar(int arg) @{ return 0; @} |
| @end example |
| |
| will give a warning for the unused parameter @code{arg}. To suppress |
| the warning write |
| |
| @example |
| int Foo::bar(int) @{ return 0; @} |
| @end example |
| |
| @node jump crosses initialization, Demangler, unused parameter warnings, User Problems |
| @section g++ objects to a declaration in a case statement |
| |
| ``The compiler objects to my declaring a variable in one of the branches |
| of a case statement. Earlier versions used to accept this code. Why?'' |
| |
| The draft standard does not allow a goto or a jump to a case label to |
| skip over an initialization of a variable or a class object. For |
| example: |
| |
| @example |
| switch ( i ) @{ |
| case 1: |
| Object obj(0); |
| ... |
| break; |
| case 2: |
| ... |
| break; |
| @} |
| @end example |
| |
| The reason is that @code{obj} is also in scope in the rest of the switch |
| statement. |
| |
| As of version 2.7.0, the compiler will object that the jump to the |
| second case level crosses the initialization of @code{obj}. Older |
| compiler versions would object only if class Object has a destructor. |
| In either case, the solution is to add a set of curly braces around |
| the case branch: |
| |
| @example |
| case 1: |
| @{ |
| Object obj(0); |
| ... |
| break; |
| @} |
| @end example |
| |
| @node Demangler, static data members, jump crosses initialization, User Problems |
| @section Where can I find a demangler? |
| |
| @cindex demangler program |
| A g++-compatible demangler named @code{c++filt} can be found in the |
| @file{binutils} distribution. This distribution (which also contains |
| the GNU linker) can be found at any GNU archive site. |
| |
| As of version 2.7.0, @code{c++filt} is included with gcc and is |
| installed automatically. Even better, it is used by the @code{collect} |
| linker, so you don't see mangled symbols anymore (except on platforms |
| that use neither collect nor the GNU linker, like Solaris). |
| |
| @node static data members, internal compiler error, Demangler, User Problems |
| @section Linker reports undefined symbols for static data members |
| |
| @cindex Static data members |
| ``g++ reports undefined symbols for all my static data members when I link, |
| even though the program works correctly for compiler XYZ. What's going on?'' |
| |
| The problem is almost certainly that you don't give definitions for |
| your static data members. If you have |
| |
| @example |
| class Foo @{ |
| ... |
| void method(); |
| static int bar; |
| @}; |
| @end example |
| |
| you have only declared that there is an int named Foo::bar and a member |
| function named Foo::method that is defined somewhere. You still need to |
| define @emph{both} method() and bar in some source file. According to |
| the draft ANSI standard, you must supply an initializer, such as |
| |
| @example |
| int Foo::bar = 0; |
| @end example |
| |
| @noindent |
| in one (and only one) source file. |
| |
| @node internal compiler error, bug reports, static data members, User Problems |
| @section What does ``Internal compiler error'' mean? |
| |
| It means that the compiler has detected a bug in itself. Unfortunately, |
| g++ still has many bugs, though it is a lot better than it used to be. |
| If you see this message, please send in a complete bug report (see next |
| section). |
| |
| @node bug reports, porting to g++, internal compiler error, User Problems |
| @section I think I have found a bug in g++. |
| |
| @cindex Bug in g++, newly found |
| ``I think I have found a bug in g++, but I'm not sure. How do I know, |
| and who should I tell?'' |
| |
| @cindex Manual, for gcc |
| First, see the excellent section on bugs and bug reports in the gcc manual |
| (which is included in the gcc distribution). As a short summary of that |
| section: if the compiler gets a fatal signal, for any input, it's a bug |
| (newer versions of g++ will ask you to send in a bug report when they |
| detect an error in themselves). Same thing for producing invalid |
| assembly code. |
| |
| When you report a bug, make sure to describe your platform (the type of |
| computer, and the version of the operating system it is running) and the |
| version of the compiler that you are running. See the output of the |
| command @code{g++ -v} if you aren't sure. Also provide enough code |
| so that the g++ maintainers can duplicate your bug. Remember that the |
| maintainers won't have your header files; one possibility is to send |
| the output of the preprocessor (use @code{g++ -E} to get this). This |
| is what a ``complete bug report'' means. |
| |
| I will add some extra notes that are C++-specific, since the notes from |
| the gcc documentation are generally C-specific. |
| |
| @cindex g++ bug report |
| First, mail your bug report to "bug-g++@@prep.ai.mit.edu". You may also |
| post to @file{gnu.g++.bug}, but it's better to use mail, particularly if you |
| have any doubt as to whether your news software generates correct reply |
| addresses. Don't mail C++ bugs to bug-gcc@@prep.ai.mit.edu. |
| |
| @strong{News:} as I write this (late February 1996) the gateway |
| connecting the bug-g++ mailing list and the @file{gnu.g++.bug} newsgroup |
| is (temporarily?) broken. Please mail, do not post bug reports. |
| |
| @cindex libg++ bug report |
| If your bug involves libg++ rather than the compiler, mail to |
| bug-lib-g++@@prep.ai.mit.edu. If you're not sure, choose one, and if you |
| guessed wrong, the maintainers will forward it to the other list. |
| |
| @cindex C++, reference books |
| @cindex ARM [Annotated C++ Ref Manual] |
| Second, if your program does one thing, and you think it should do |
| something else, it is best to consult a good reference if in doubt. |
| The standard reference is the draft working paper from the ANSI/ISO |
| C++ standardization committee, which you can get on the net. |
| For PostScript and PDF (Adobe Acrobat) versions, see the |
| archive at @file{ftp://research.att.com/dist/stdc++/WP}. For HTML and ASCII |
| versions, see @file{ftp://ftp.cygnus.com/pub/g++}. On the World Wide Web, see |
| @file{http://www.cygnus.com/misc/wp/}. |
| |
| An older |
| standard reference is "The Annotated C++ Reference Manual", by Ellis and |
| Stroustrup (copyright 1990, ISBN #0-201-51459-1). This is what they're |
| talking about on the net when they refer to ``the ARM''. But you should |
| know that changes have been made to the language since then. |
| |
| The ANSI/ISO C++ standards committee have adopted some changes to the |
| C++ language since the publication of the original ARM, and newer |
| versions of g++ (2.5.x and later) support some of these changes, notably |
| the mutable keyword (added in 2.5.0), the bool type (added in 2.6.0), |
| and changes in the scope of variables defined in for statements (added |
| in 2.7.0). |
| You can obtain an addendum to the ARM explaining many of these changes by FTP |
| from @file{ftp://ftp.std.com/AW/stroustrup2e/new_iso.ps}. |
| |
| @cindex AT&T cfront |
| Note that the behavior of (any version of) AT&T's "cfront" compiler is |
| NOT the standard for the language. |
| |
| @node porting to g++, name mangling, bug reports, User Problems |
| @section Porting programs from other compilers to g++ |
| |
| ``I have a program that runs on <some other C++ compiler>, and I want |
| to get it running under g++. Is there anything I should watch out |
| for?'' |
| |
| @cindex Porting to g++ |
| |
| Note that g++ supports many of the newer keywords that have recently |
| been added to the language. Your other C++ compiler may not support |
| them, so you may need to rename variables and members that conflict |
| with these keywords. |
| |
| There are two other reasons why a program that worked under one compiler |
| might fail under another: your program may depend on the order of |
| evaluation of side effects in an expression, or it may depend on the |
| lifetime of a temporary (you may be assuming that a temporary object |
| "lives" longer than the standard guarantees). As an example of the |
| first: |
| |
| @example |
| void func(int,int); |
| |
| int i = 3; |
| func(i++,i++); |
| @end example |
| |
| @cindex Order of evaluation, problems in porting |
| Novice programmers think that the increments will be evaluated in strict |
| left-to-right order. Neither C nor C++ guarantees this; the second |
| increment might happen first, for example. func might get 3,4, or it |
| might get 4,3. |
| |
| @cindex Classes, problems in porting |
| @cindex Problems in porting, class |
| The second problem often happens with classes like the libg++ String |
| class. Let's say I have |
| |
| @example |
| String func1(); |
| void func2(const char*); |
| @end example |
| |
| and I say |
| |
| @example |
| func2(func1()); |
| @end example |
| |
| because I know that class String has an "operator const char*". So what |
| really happens is |
| |
| @example |
| func2(func1().convert()); |
| @end example |
| |
| @cindex temporaries |
| where I'm pretending I have a convert() method that is the same as the |
| cast. This is unsafe in g++ versions before 2.6.0, because the |
| temporary String object may be deleted after its last use (the call to |
| the conversion function), leaving the pointer pointing to garbage, so by |
| the time func2 is called, it gets an invalid argument. |
| |
| @cindex ANSI draft standard |
| Both the cfront and the old g++ behaviors are legal according to the ARM, |
| but the powers that be have decided that compiler writers were given |
| too much freedom here. |
| |
| The ANSI C++ committee has now come to a resolution of the lifetime of |
| temporaries problem: they specify that temporaries should be deleted at |
| end-of-statement (and at a couple of other points). This means that g++ |
| versions before 2.6.0 now delete temporaries too early, and cfront |
| deletes temporaries too late. As of version 2.6.0, g++ does things |
| according to the new standard. |
| |
| @cindex Scope, problems in porting |
| @cindex Problems in porting, scope |
| For now, the safe way to write such code is to give the temporary a name, |
| which forces it to live until the end of the scope of the name. For |
| example: |
| |
| @example |
| String& tmp = func1(); |
| func2(tmp); |
| @end example |
| |
| Finally, like all compilers (but especially C++ compilers, it seems), |
| g++ has bugs, and you may have tweaked one. If so, please file a bug |
| report (after checking the above issues). |
| |
| @node name mangling, problems linking with other libraries, porting to g++, User Problems |
| @section Why does g++ mangle names differently from other C++ compilers? |
| |
| See the answer to the next question. |
| @cindex Mangling names |
| |
| @node problems linking with other libraries, documentation, name mangling, User Problems |
| @section Why can't g++ code link with code from other C++ compilers? |
| |
| ``Why can't I link g++-compiled programs against libraries compiled by |
| some other C++ compiler?'' |
| |
| @cindex Mangling names |
| @cindex Cygnus Support |
| Some people think that, |
| if only the FSF and Cygnus Support folks would stop being |
| stubborn and mangle names the same way that, say, cfront does, then any |
| g++-compiled program would link successfully against any cfront-compiled |
| library and vice versa. Name mangling is the least of the problems. |
| Compilers differ as to how objects are laid out, how multiple inheritance |
| is implemented, how virtual function calls are handled, and so on, so if |
| the name mangling were made the same, your programs would link against |
| libraries provided from other compilers but then crash when run. For this |
| reason, the ARM @emph{encourages} compiler writers to make their name mangling |
| different from that of other compilers for the same platform. |
| Incompatible libraries are then detected at link time, rather than at run |
| time. |
| @cindex ARM [Annotated C++ Ref Manual] |
| @cindex Compiler differences |
| |
| @node documentation, templates, problems linking with other libraries, User Problems |
| @section What documentation exists for g++ 2.x? |
| |
| @cindex g++, documentation |
| Relatively little. |
| While the gcc manual that comes with the distribution has some coverage |
| of the C++ part of the compiler, it focuses mainly on the C compiler |
| (though the information on the ``back end'' pertains to C++ as well). |
| Still, there is useful information on the command line options and the |
| #pragma interface and #pragma implementation directives in the manual, |
| and there is a useful section on template instantiation in the 2.6 version. |
| There is a Unix-style manual entry, "g++.1", in the gcc-2.x |
| distribution; the information here is a subset of what is in the manual. |
| |
| You can buy a nicely printed and bound copy of this manual from the FSF; |
| see above for ordering information. |
| |
| A draft of a document describing the g++ internals appears in the gcc |
| distribution (called g++int.texi); it is incomplete but gives lots of |
| information. |
| |
| For class libraries, there are several resources available: |
| |
| @itemize @bullet |
| @item |
| The libg++ distribution has a manual |
| @file{libg++/libg++.texi} describing the old libg++ classes, and |
| another manual @file{libio/iostream.texi} describing the iostreams |
| implementation. |
| @item |
| While there is no libg++-specific document describing the STL |
| implementation, SGI's web site, at @file{http://www.sgi.com/Technology/STL/}, |
| is an excellent resource. |
| @end itemize |
| |
| @node templates, undefined templates, documentation, User Problems |
| @section Problems with the template implementation |
| |
| @cindex g++, template support |
| @cindex Templates |
| |
| g++ does not implement a separate pass to instantiate template functions |
| and classes at this point; for this reason, it will not work, for the most |
| part, to declare your template functions in one file and define them in |
| another. The compiler will need to see the entire definition of the |
| function, and will generate a static copy of the function in each file |
| in which it is used. |
| |
| (The experimental template repository code (@pxref{repository}) that |
| can be added to 2.7.0 or later does implement a separate pass, but there |
| is still no searching of files that the compiler never saw). |
| |
| @cindex -fno-implicit-templates |
| For version 2.6.0, however, a new switch @code{-fno-implicit-templates} |
| was added; with this switch, templates are expanded only under user |
| control. I recommend that all g++ users that use templates read the |
| section ``Template Instantiation'' in the gcc manual (version 2.6.x |
| and newer). g++ now supports explicit template expansion using the |
| syntax from the latest C++ working paper: |
| |
| @example |
| template class A<int>; |
| template ostream& operator << (ostream&, const A<int>&); |
| @end example |
| |
| @cindex template limitations |
| As of version 2.6.3, there are still a few limitations in the template |
| implementation besides the above (thanks to Jason Merrill for this info): |
| These are still present in version 2.7.2, but a new implementation of |
| templates planned for version 2.8 will eliminate them. |
| |
| @enumerate 1 |
| @item |
| Static data member templates are not supported. You can work around |
| this by explicitly declaring the static variable for each template |
| specialization: |
| |
| @example |
| template <class T> struct A @{ |
| static T t; |
| @}; |
| |
| template <class T> T A<T>::t = 0; // gets bogus error |
| int A<int>::t = 0; // OK (workaround) |
| @end example |
| |
| (still a limitation in 2.7.2) |
| |
| @item |
| Template member names are not available when defining member function |
| templates. |
| |
| @example |
| template <class T> struct A @{ |
| typedef T foo; |
| void f (foo); |
| void g (foo arg) @{ ... @}; // this works |
| @}; |
| |
| template <class T> void A<T>::f (foo) @{ @} // gets bogus error |
| @end example |
| |
| @item |
| Templates are instantiated using the parser. This results in two |
| problems: |
| |
| a) Class templates are instantiated in some situations where such |
| instantiation should not occur. |
| |
| @example |
| template <class T> class A @{ @}; |
| A<int> *aip = 0; // should not instantiate A<int> (but does) |
| @end example |
| |
| b) Function templates cannot be inlined at the site of their |
| instantiation. |
| |
| @example |
| template <class T> inline T min (T a, T b) @{ return a < b ? a : b; @} |
| |
| void f () @{ |
| int i = min (1, 0); // not inlined |
| @} |
| |
| void g () @{ |
| int j = min (1, 0); // inlined |
| @} |
| @end example |
| |
| A workaround that works in version 2.6.1 and later is to specify |
| |
| @example |
| extern template int min (int, int); |
| @end example |
| |
| before @code{f()}; this will force it to be instantiated (though not |
| emitted). |
| |
| @item |
| Member function templates are always instantiated when their containing |
| class is. This is wrong. |
| @end enumerate |
| |
| @node undefined templates, redundant templates, templates, User Problems |
| @section I get undefined symbols when using templates |
| |
| (Thanks to Jason Merrill for this section). |
| |
| @cindex template instantiation |
| g++ does not automatically instantiate templates defined in other files. |
| Because of this, code written for cfront will often produce undefined |
| symbol errors when compiled with g++. You need to tell g++ which template |
| instances you want, by explicitly instantiating them in the file where they |
| are defined. For instance, given the files |
| |
| @file{templates.h}: |
| @example |
| template <class T> |
| class A @{ |
| public: |
| void f (); |
| T t; |
| @}; |
| |
| template <class T> void g (T a); |
| @end example |
| |
| @file{templates.cc}: |
| @example |
| #include "templates.h" |
| |
| template <class T> |
| void A<T>::f () @{ @} |
| |
| template <class T> |
| void g (T a) @{ @} |
| @end example |
| |
| |
| main.cc: |
| @example |
| #include "templates.h" |
| |
| main () |
| @{ |
| A<int> a; |
| a.f (); |
| g (a); |
| @} |
| @end example |
| |
| compiling everything with @code{g++ main.cc templates.cc} will result in |
| undefined symbol errors for @samp{A<int>::f ()} and @samp{g (A<int>)}. To |
| fix these errors, add the lines |
| |
| @example |
| template class A<int>; |
| template void g (A<int>); |
| @end example |
| |
| to the bottom of @samp{templates.cc} and recompile. |
| |
| @node redundant templates, Standard Template Library, undefined templates, User Problems |
| @section I get multiply defined symbols using templates |
| |
| You may be running into a bug that was introduced in version 2.6.1 |
| (and is still present in 2.6.3) that generated external linkage |
| for templates even when neither @code{-fexternal-templates} nor |
| @code{-fno-implicit-templates} is specified. There is a patch for |
| this problem at @* |
| @file{ftp://ftp.cygnus.com/pub/g++/gcc-2.6.3-template-fix}. |
| |
| I recommend either applying the patch or |
| using @code{-fno-implicit-templates} |
| together with explicit template instantiation as described in previous |
| sections. |
| |
| This bug is fixed in 2.7.0. |
| |
| @node Standard Template Library, STL and string, redundant templates, User Problems |
| @section Does g++ support the Standard Template Library? |
| |
| @cindex STL |
| @cindex Standard Template Library |
| The Standard Template Library (STL) uses many of the extensions that the |
| ANSI/ISO committee has made to templates, and g++ doesn't support |
| some of these yet. So if you grab HP's free implementation of STL it |
| isn't going to work. However, starting with libg++-2.6.2 libg++ contains a |
| hacked version of STL, based on work by Carsten Bormann, which permits |
| g++ to compile at least the containers (thanks to Per Bothner for this |
| text). |
| |
| Actually, as of libg++ version 2.7.2 most of this works quite well, most |
| of the time; |
| I've succeeded |
| in making significant use of it. |
| Almost all of the ObjectSpace examples (a set of |
| over 200 simple examples of STL usage) now work. |
| |
| When version 2.8.0 is out (with its complete redesign of the template |
| implementation) a much more complete implementation of the |
| STL (based on a newer free implementation from SGI) will be included. |
| In the meantime, a group at the Moscow Center for Sparc Technology has |
| a port of the SGI STL implementation that mostly works with gcc-2.7.2. |
| See |
| @file{http://www.ipmce.su/people/fbp/stl/stlport.html}. |
| |
| In addition, there are several commercial suppliers of STL implementations; |
| ObjectSpace's version supports gcc-2.7.x. |
| |
| Mumit Khan has produced an ``STL newbie guide'' with lots of information |
| on using STL with gcc. See |
| |
| @file{http://www.xraylith.wisc.edu/~khan/software/stl/STL.newbie.html} |
| |
| @node STL and string, exceptions, Standard Template Library, User Problems |
| @section I'm having problems mixing STL and the standard string class |
| |
| This is due to a bug in g++ version 2.7.2 and 2.7.2.1; the compiler |
| is confused by the operator declarations. There is an easy workaround, |
| however; just make sure that the @code{<string>} header is included |
| before any STL headers. That is, just say |
| |
| @example |
| #include <string> |
| @end example |
| |
| before any other @code{#include} directives. |
| |
| Unfortunately, this doesn't solve all problems; you may still have |
| difficulty with the relational operators !=, <=, >, and >=, thanks |
| to a conflict with the very general definition of these operators |
| in function.h. One trick that sometimes works is to try to use == |
| and < in your code instead of the other operators. Another is to |
| use a derived class of <string>. The only completely satisfactory |
| solution, I'm afraid, is to wait for the new release. |
| |
| @node exceptions, namespaces, STL and string, User Problems |
| @section Problems and limitations with exceptions |
| |
| Recent g++ versions provide limited support for exceptions. You must |
| provide the @code{-fhandle-exceptions} flag to enable exception |
| handling. As of version 2.7.2, exceptions may not work properly |
| (and you may get odd error messages when compiling) if you turn |
| on optimization (the @code{-O} flag). |
| |
| You must give the @code{-frtti} switch to enable catching |
| of derived exception objects with handlers for the base exception class; |
| if @code{-frtti} is not given, only exact type matching works. |
| |
| For exception handling to work with 2.7.0 your CPU must be a SPARC, |
| RS6000/PowerPC, 386/486/Pentium, or ARM. Release 2.7.1 added support |
| for the Alpha, and ``m68k is rumored to work on some platforms'' |
| and ``VAX may also work'' (according to Mike Stump). |
| @emph{It still doesn't work on HP-PA or MIPS platforms.} |
| |
| @node namespaces, agreement with standards, exceptions, User Problems |
| @section Does g++ support namespaces? |
| |
| As of version 2.7.2, g++ recognizes the keywords @code{namespace} and |
| @code{using}, and there is some rudimentary code present, but almost |
| nothing connected with namespaces works yet. It appears that this will |
| still be true when 2.8.0 is released. |
| |
| @node agreement with standards, compiling standard libraries, namespaces, User Problems |
| @section What are the differences between g++ and the ARM specification of C++? |
| |
| @cindex ARM [Annotated C++ Ref Manual] |
| @cindex exceptions |
| As of version 2.7.0, g++ has exception support on most but not all |
| platforms |
| (no support on MIPS-based platforms yet), but |
| it doesn't work right if optimizaton is enabled, which means the |
| exception |
| implementation is still |
| not really ready for production use. |
| |
| |
| @cindex mutable |
| Some features that the ANSI/ISO standardization committee has voted in |
| that don't appear in the ARM are supported, notably the @code{mutable} |
| keyword, in version 2.5.x. 2.6.x adds support for the built-in boolean |
| type @code{bool}, with constants @code{true} and @code{false}. The |
| beginnings of run-time type identification are present, so there are |
| more reserved words: @code{typeid}, @code{static_cast}, |
| @code{reinterpret_cast}, @code{const_cast}, and @code{dynamic_cast}. |
| |
| @cindex g++ bugs |
| As with any beta-test compiler, there are bugs. You can help improve |
| the compiler by submitting detailed bug reports. |
| |
| One of the weakest areas of g++ other than templates is the resolution |
| of overloaded functions and operators in complex cases. The usual |
| symptom is that in a case where the ARM says that it is ambiguous which |
| function should be chosen, g++ chooses one (often the first one |
| declared). This is usually not a problem when porting C++ code from |
| other compilers to g++, but shows up as errors when code developed under |
| g++ is ported to other compilers. (I believe this is no longer a |
| significant problem in 2.7.0). |
| |
| [A full bug list would be very long indeed, so I won't put one here. |
| I may add a list of frequently-reported bugs and "non-bugs" like the |
| static class members issue mentioned above]. |
| |
| @node compiling standard libraries, debugging on SVR4 systems, agreement with standards, User Problems |
| @section Will g++ compile InterViews? The NIH class library? Rogue Wave? |
| |
| @cindex NIH class library |
| @cindex NIHCL with g++ |
| The NIH class library uses a non-portable, compiler-dependent hack |
| to initialize itself, which makes life difficult for g++ users. |
| It will not work without modification, and I don't know what modifications |
| are required or whether anyone has done them successfully. |
| |
| In short, it's not going to happen any time soon (previous FAQs referred |
| to patches that a new NIHCL release would hopefully contain, but this |
| hasn't happened). |
| |
| @strong{Note:} I thought I saw an item indicating that someone |
| @emph{had} patched NIHCL to work with g++. Any pointers? |
| |
| @cindex InterViews |
| I think that as of version 2.5.6, the standard g++ will compile the |
| standard 3.1 InterViews completely successfully. |
| Note that you'll need the @code{-fno-for-scope} flag |
| if you use gcc-2.7.0; with 2.7.2 you may be able to omit this flag |
| but you'll get warnings. |
| |
| @cindex Rogue Wave |
| According to Jason Merrill, gcc-2.7.0 and newer works with Rogue |
| Wave's @code{tools.h++} class library, but you may want to grab |
| @file{ftp://ftp.cygnus.com/pub/g++/Tools.h++-6.1-patch}. Again, |
| you'll need the @code{-fno-for-scope} flag since Rogue Wave hasn't |
| fixed their code to comply with the new standard yet. |
| |
| @node debugging on SVR4 systems, debugging problems on Solaris, compiling standard libraries, User Problems |
| @section Debugging on SVR4 systems |
| @cindex System VR4, debugging |
| |
| ``How do I get debugging to work on my System V Release 4 system?'' |
| |
| @cindex DWARF debug format |
| |
| Most systems based on System V Release 4 (except Solaris) encode symbolic |
| debugging information in a format known as `DWARF'. |
| |
| Although the GNU C compiler already knows how to write out symbolic debugging |
| information in the DWARF format, the GNU C++ compiler does not yet have this |
| feature yet. However, work is in progress for DWARF 2 debug support for |
| gcc and g++ and will be available in a future release (probably 2.8.0). |
| |
| @cindex stabs |
| @cindex --with-stabs |
| |
| In the meantime, you @emph{can} get g++ debugging under SVR4 systems by |
| configuring gcc with the @code{--with-stabs} option. This causes gcc to |
| use an alternate debugging format, one more like that used under SunOS4. |
| You won't need to do anything special to GDB; it will always understand |
| the ``stabs'' format. |
| |
| @node debugging problems on Solaris, X11 conflicts with libg++, debugging on SVR4 systems, User Problems |
| @section debugging problems on Solaris |
| |
| ``I'm on Solaris, and gdb says it doesn't know about some of my local |
| symbols. Help!'' |
| |
| This problem was introduced in gcc 2.7.2; debug symbols for |
| locals that aren't declared at the beginning of a block come out in the |
| wrong order, and gdb can't find such symbols. |
| |
| This problem is fixed in gcc-2.7.2.1. |
| |
| @node X11 conflicts with libg++, assignment to streams, debugging problems on Solaris, User Problems |
| @section X11 conflicts with libg++ in definition of String |
| @cindex String, conflicts in definition |
| |
| ``X11 and Motif define String, and this conflicts with the String class |
| in libg++. How can I use both together?'' |
| |
| One possible method is the following: |
| |
| @example |
| #define String XString |
| #include <X11/Intrinsic.h> |
| /* include other X11 and Motif headers */ |
| #undef String |
| @end example |
| |
| and remember to use the correct @code{String} or @code{XString} when |
| you declare things later. |
| |
| @node assignment to streams, , X11 conflicts with libg++, User Problems |
| @section Why can't I assign one stream to another? |
| |
| [ Thanks to Per Bothner and Jerry Schwarz for this section. ] |
| |
| Assigning one stream to another seems like a reasonable thing to do, but |
| it's a bad idea. Usually, this comes up because people want to assign |
| to @code{cout}. This is poor style, especially for libraries, and is |
| contrary to good object-oriented design. (Libraries that write directly |
| to @code{cout} are less flexible, modular, and object-oriented). |
| |
| The iostream classes do not allow assigning to arbitrary streams, because |
| this can violate typing: |
| |
| @example |
| ifstream foo ("foo"); |
| istrstream str(...); |
| foo = str; |
| foo->close (); /* Oops! Not defined for istrstream! */ |
| @end example |
| |
| @cindex assignment to cout |
| |
| The original cfront implementation of iostreams by Jerry Schwarz allows |
| you to assign to @code{cin}, @code{cout}, @code{cerr}, and @code{clog}, |
| but this is not part of the draft standard for iostreams and generally |
| isn't considered a good idea, so standard-conforming code shouldn't use |
| this technique. |
| |
| The GNU implementation of iostream did not support assigning to |
| @code{cin}, @code{cout}, @code{cerr}, and @code{clog} |
| for quite a while, but it now does, for backward |
| compatibility with cfront iostream (versions 2.6.1 and later of libg++). |
| |
| The ANSI/ISO C++ Working Paper does provide ways of changing the |
| streambuf associated with a stream. Assignment isn't allowed; |
| there is an explicit named member that must be used. |
| |
| However, it is not wise to do this, and the results are confusing. For |
| example: @code{fstream::rdbuf} is supposed to return the @emph{original} |
| filebuf, not the one you assigned. (This is not yet implemented in GNU |
| iostream.) This must be so because @code{fstream::rdbuf} is defined to |
| return a @code{filebuf *}. |
| |
| @node legalities, index, User Problems, Top |
| @chapter What are the rules for shipping code built with g++ and libg++? |
| @cindex Shipping rules |
| @cindex GPL [GNU Public License] |
| |
| ``Is it is possible to distribute programs for profit that are created |
| with g++ and use the g++ libraries?'' |
| |
| I am not a lawyer, and this is not legal advice. In any case, I have |
| little interest in telling people how to violate the spirit of the |
| GNU licenses without violating the letter. This section tells you |
| how to comply with the intention of the GNU licenses as best I understand |
| them. |
| |
| @cindex FSF [Free Software Foundation] |
| The FSF has no objection to your making money. Its only interest is that |
| source code to their programs, and libraries, and to modified versions of |
| their programs and libraries, is always available. |
| |
| The short answer is that you do not need to release the source to |
| your program, but you can't just ship a stripped executable either, |
| unless you use only the subset of libg++ that includes the iostreams |
| classes (see discussion below) or the new libstdc++ library (available |
| in libg++ 2.6.2 and later). |
| |
| Compiling your code with a GNU compiler does not affect its copyright; |
| it is still yours. However, in order to ship code that links in a GNU |
| library such as libg++ there are certain rules you must follow. The |
| rules are described in the file COPYING.LIB that accompanies gcc |
| distributions; it is also included in the libg++ distribution. |
| See that file for the exact rules. The agreement is called the |
| Library GNU Public License or LGPL. It is much "looser" than the |
| GNU Public License, or GPL, that covers must GNU programs. |
| |
| @cindex libg++, shipping code |
| Here's the deal: let's say that you use some version of libg++, |
| completely unchanged, in your software, and you want to ship only |
| a binary form of your code. You can do this, but there are several |
| special requirements. If you want to use libg++ but ship only object |
| code for your code, you have to ship source for libg++ (or ensure |
| somehow that your customer already has the source for the exact |
| version you are using), and ship your application in linkable form. |
| You cannot forbid your customer from reverse-engineering or extending |
| your program by exploiting its linkable form. |
| |
| @cindex libg++, modifying |
| Furthermore, if you modify libg++ itself, you must provide source |
| for your modifications (making a derived class does not count as |
| modifying the library -- that is "a work that uses the library"). |
| |
| @cindex special copying conditions for iostreams |
| For certain portions of libg++ that implement required parts of the C++ |
| language (such as iostreams and other standard classes), the FSF has |
| loosened the copyright requirement still more by adding the ``special |
| exception'' clause, which reads as follows: |
| |
| @quotation |
| As a special exception, if you link this library with files |
| compiled with GCC to produce an executable, this does not cause |
| the resulting executable to be covered by the GNU General Public License. |
| This exception does not however invalidate any other reasons why |
| the executable file might be covered by the GNU General Public License. |
| @end quotation |
| |
| If your only use of libg++ uses code with this exception, you may ship |
| stripped executables or license your executables under different |
| conditions without fear of violating an FSF copyright. It is the intent |
| of FSF and Cygnus that, as the other classes required by the ANSI/ISO |
| draft standard are developed, these will also be placed under this |
| ``special exception'' license. |
| The code in the new libstdc++ library, intended to implement standard |
| classes as defined by ANSI/ISO, is also licensed this way. |
| |
| To avoid coming under the influence of the LGPL, you can link with |
| @file{-liostream} rather than @file{-lg++} (for version 2.6.x and |
| earlier), or @file{-lstdc++} now that it is available. In version 2.7.0 |
| all the standard classes are in @file{-lstdc++}; you can do the link |
| step with @code{c++} instead of @code{g++} to search only the |
| @file{-lstdc++} library and avoid the LGPL'ed code in @file{-lg++}. |
| |
| If you wish to discuss legal issues connected with GNU software on the |
| net, please use @file{gnu.misc.discuss}, not the technical newsgroups. |
| |
| @node index, , legalities, Top |
| @comment node-name, next, previous, up |
| @appendix Concept Index |
| |
| @printindex cp |
| |
| @page |
| @contents |
| @bye |