diff options
| -rw-r--r-- | gcc/cp/ChangeLog | 5 | ||||
| -rw-r--r-- | gcc/cp/Makefile.in | 29 | ||||
| -rw-r--r-- | gcc/cp/g++FAQ.texi | 2423 |
3 files changed, 5 insertions, 2452 deletions
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog index fdbec66..2bee0441 100644 --- a/gcc/cp/ChangeLog +++ b/gcc/cp/ChangeLog @@ -1,3 +1,8 @@ +Sun Jul 25 15:24:21 1999 Jeffrey A Law (law@cygnus.com) + + * g++FAQ.texi: Deleted per Joe Buck's request. + * Makefile.in: Corresponding changes. + 1999-07-23 Jason Merrill <jason@yorick.cygnus.com> * lex.c: Sync with C frontend. diff --git a/gcc/cp/Makefile.in b/gcc/cp/Makefile.in index d876a14..edd3379 100644 --- a/gcc/cp/Makefile.in +++ b/gcc/cp/Makefile.in @@ -322,32 +322,3 @@ TAGS: force .PHONY: TAGS force: - -g++FAQ.info: $(srcdir)/g++FAQ.texi - $(MAKEINFO) --no-split -o ./g++FAQ.info $(srcdir)/g++FAQ.texi - -# Preprocess the texi file so that the final document will have -# hyperlinks. -# It would be nice if texi2html could do something like this itself. - -# Assumption 1: the FAQ puts all http: and ftp: links in a @file{...}. -# Assumption 2: newsgroups are like @file{comp.foo} -# Assumption 3: email addresses match the regexp shown. - -g++FAQ.html: $(srcdir)/g++FAQ.texi - mkdir work - sed -e 's?@file{\([fth]*p://[^}]*\)}?@strong{<A HREF="\1">\1</A>}?' \ - -e 's?@file{\(comp\.[-a-z+.]*\)}?<A HREF="news:\1">\1</A>?' \ - -e 's?@file{\(gnu\.[-a-z+.]*\)}?<A HREF="news:\1">\1</A>?' \ - -e 's?\([.+a-zA-Z0-9-]*@@[.a-zA-Z0-9-]*[a-zA-Z0-9]\)?<A HREF="mailto:\1">\1</A>?' \ - $(srcdir)/g++FAQ.texi > work/g++FAQ.texi - cd work; texi2html g++FAQ.texi - mv work/*.html . - rm -r work - -# Make plain-text form. - -g++FAQ.txt: $(srcdir)/g++FAQ.texi - $(MAKEINFO) --no-split --no-headers -o - $(srcdir)/g++FAQ.texi |\ - sed '/^Concept Index/,$$d' > g++FAQ.txt - diff --git a/gcc/cp/g++FAQ.texi b/gcc/cp/g++FAQ.texi deleted file mode 100644 index 3cbec50..0000000 --- a/gcc/cp/g++FAQ.texi +++ /dev/null @@ -1,2423 +0,0 @@ -\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: %W% %G% -@c %**end of header - -@iftex -@finalout -@end iftex -@titlepage -@title G++ FAQ -@subtitle Frequently asked questions about the GNU C++ compiler -@subtitle June 8, 1998 -@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}. - -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++. If you ignore this -request your message to me may be deleted without a reply. Sorry. - -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? -* egcs and 2.8.x:: The next generation(s) of g++ -* 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:: What are the latest versions of g++ and libraries? -* g++ for Unix:: How do I get g++ for Unix? -* getting-egcs:: How do I get egcs? -* g++ for HP:: -* g++ for Solaris 2.x:: -* g++ for other platforms:: -* 1.x vs 2.x versions:: - -The Next Generation(s) of g++ - -* new-in-2.8.x:: What's new in gcc 2.8.x? -* egcs-intro:: What is egcs? -* egcs-whats-new:: What's new in egcs vs 2.7.2? -* egcs-bug-fixes:: What was fixed in the latest egcs releases? -* egcs-linux:: If I install on Linux, will it overwrite my libraries? -* egcs-run-both:: How can I run both egcs and an FSF release? -* egcs-vs-2.8.x:: How will egcs affect 2.8.x? -* egcs-robustness:: How robust is egcs? - -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:: What's changed in 2.7.x from earlier versions -* libstdc++:: - -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, egcs and 2.8.x, 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:: What is the latest version of gcc/g++/libg++? -* g++ for Unix:: How do I get a copy of g++ for Unix? -* getting-egcs:: How do I get egcs? -* g++ for HP:: Getting g++ for the HP precision architecture -* g++ for Solaris 2.x:: Getting g++ for Solaris -* 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 egcs release - -The newest release from the egcs project (on the Web: -@file{http://www.cygnus.com/egcs/}) is egcs-1.0.3, released May 15, -1998. - -@cindex gcc/g++, version date -The current version of gcc/g++ is 2.8.1, released March 4, 1998. -This release fixes some bugs in the 2.8.x release from January. -It is a huge improvement over the 2.7.x releases. - -libg++ has now been deprecated (that is, it is no longer really -supported), so gcc2.8.1 users need to grab libstdc++-2.8.1 from -their favorite GNU site (egcs users don't need to get this separately -as it is bundled with egcs). However, there is an 'add-on' libg++ 2.8.1 -mini-release. If you want to use it, you need to combine it with -libstdc++ 2.8.1. - -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}). -Folks who need modern C++ features should upgrade to 2.8.1 or egcs. - -For some non-Unix platforms, the latest port of gcc may be an earlier -version (2.7.2, 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.7.x (for the latest x you can find) with gcc version 2.7.2.1. - -From version 2.8.0 on, you don't need libg++, you only need libstdc++ -(again, the latest version with the same two leading digits as the -version of g++ you use). - -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, g++ 1.x is only of -historical interest (since the C++ language has changed so much). - -@node g++ for Unix, getting-egcs, 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 libstdc++ -Don't forget to retrieve libstdc++ as well! - -@node getting-egcs, g++ for HP, g++ for Unix, basics -@section How do I get egcs? - -See @xref{egcs-intro} to find out what egcs is. - -You can obtain egcs either by FTP or with a Web browser. To do the -latter, start from @file{http://egcs.cygnus.com/}. The master -FTP site is @file{ftp://ftp.cygnus.com/pub/egcs/releases}, however -you'll probably get a faster download if you use a mirror site. -Mirror sites also have egcs snapshots unless otherwise noted. -@itemize @bullet -@item -US (west coast): @file{ftp://go.cygnus.com/pub/ftp.cygnus.com/egcs/} -@item -US (east coast): @file{ftp://ftp.goof.com/pub/pcg/egcs/} -or (for releases only): @file{ftp://cambridge.cygnus.com/pub/egcs/} -@item -US (Arizona): @file{ftp://ftp.ninemoons.com/pub/mirrors/egcs/} -@item -UK: @file{ftp://sunsite.doc.ic.ac.uk/Mirrors/egcs.cygnus.com/pub/egcs/} -@item -Austria: @file{ftp://gd.tuwien.ac.at/gnu/egcs} -@item -France: @file{ftp://ftp.ilog.fr/pub/mirrors/egcs/} or -@file{ftp://ftp.lip6.fr/pub/egcs} -@item -Czech Republic: @file{ftp://sunsite.mff.cuni.cz/pub/GNU/egcs/} -@item -Denmark: @file{ftp://sunsite.auc.dk/pub/egcs/} -@item -Germany @file{ftp://ftp.fu-berlin.de/unix/languages/egcs/} or -@file{ftp://ftp.gwdg.de/pub/cygnus/egcs/} -@item -Poland: @file{ftp://sunsite.icm.edu.pl/pub/programming/egcs/} -@item -Sweden: @file{ftp://ftp.sunet.se/pub/gnu/egcs/} -@item -Brasil (releases only, no snapshots): -@file{ftp://ftp.unicamp.br/pub/gnu/=EXTRA=/cygnus/egcs/} -@item -Portugal: @file{ftp://ftp.lca.uevora.pt/pub/egcs/} -@item -Romania: @file{ftp://ftp.lbi.ro/pub/egcs/} -@item -Australia/NZ (release only): @file{ftp://moshpit.cygnus.com/pub/egcs/} -@end itemize - -@node g++ for HP, g++ for Solaris 2.x, getting-egcs, 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 can obtain and install prebuilt binaries of gcc. - - -@cindex Solaris pkgadd utility -The WWW site @file{http://smc.vnet.net/} -contains various -GNU and freeware programs for Solaris 2.5 or 2.6, for either the Sparc -or Intel platforms. These are -packaged to enable easy installation using the Solaris ``pkgadd'' utility. -These include GNU emacs, gcc, gdb, perl, and others. - -You can find also find prebuilt binaries of many GNU tools, including the -compiler, at @file{http://sunsite.unc.edu/pub/solaris/}. - -@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.8.1 (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 egcs and 2.8.x, installation, basics, Top -@chapter The Next Generation(s) of g++ - -@menu -* new-in-2.8.x:: What's new in gcc 2.8.x? -* egcs-intro:: What is egcs? -* egcs-whats-new:: What's new in egcs vs 2.7.2? -* egcs-bug-fixes:: What was fixed in the latest egcs releases? -* egcs-linux:: If I install on Linux, will it overwrite my libraries? -* egcs-run-both:: How can I run both egcs and an FSF release? -* egcs-vs-2.8.x:: How will egcs affect 2.8.x? -* egcs-robustness:: How robust is egcs? -@end menu - -@node new-in-2.8.x, egcs-intro, egcs and 2.8.x, egcs and 2.8.x -@section What's new in gcc/g++ 2.8.x? - -After a two-year wait, gcc 2.8.0 was released in January 1998, along -with libstdc++-2.8.0 and libg++-2.8.0. This has been followed up in -March by the 2.8.1 release of all three packages, though libg++-2.8.1 -is an "add-on" (it does not contain libstdc++ anymore). Note that -libstdc++ is required. - -For those familiar with egcs, the most obvious difference between -gcc-2.8.x and egcs is the packaging: egcs is bundled with -libstdc++, and gcc-2.8.x does not contain the class library. Otherwise, -except for the lack of the @code{-frepo} option and some bug fixes -that have not yet made it into gcc-2.8.x, C++ users will find the -two compilers to be almost the same at this stage, other than that 2.8.x -users may get more bogus warnings with -Wall and optimization because -some fixes to flow analysis in the presence of exceptions that egcs made -are not yet present in gcc 2.8.x (as of 2.8.1). - -The flow analysis problem in 2.8.1 produces bad code in some cases, not -just spurious errors. It only affects code that actually throws an -exception, and only the path corresponding to a thrown exception gets -misoptimized. If this happens, you can try reducing the level of -optimization. - -Because the new feature lists for egcs and gcc 2.8 are almost the same, -please see @xref{egcs-whats-new} for a list of new features. It is a -fairly long list. - -@node egcs-intro, egcs-whats-new, new-in-2.8.x, egcs and 2.8.x -@section What is egcs? - -egcs is the experimental GNU compiler system (see -@file{http://www.cygnus.com/egcs} on the Web). It is an effort to -accelerate development of new gcc features by providing a more open -development model than gcc has traditionally used. - -The first egcs release, egcs-1.0, came out on December 3, 1997. -The current release is egcs-1.0.3, released May 15, 1998. - -Questions not addressed here may be answered in the egcs FAQ -(@file{http://www.cygnus.com/egcs/faq.html}). - -@node egcs-whats-new, egcs-bug-fixes, egcs-intro, egcs and 2.8.x -@section What new C++ features are in egcs? - -@strong{Note}: unless indicated otherwise, these features are also -present in g++ 2.8.x. - -@itemize @bullet -@item -@cindex integrated libstdc++ - -The standard C++ classes are integrated with the egcs release (but -@strong{not} for gcc-2.8.x, which does not include the class libraries). -libg++ is not being -supported, though an add-on version that will work with egcs can be found at -@file{ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.0b6.6.tar.gz}, -thanks to H.J. Lu. The compiler and library are configured and built -in one step. - -@item -@cindex new template implementation -A completely new template implementation, much closer to the draft -standard. Limitations in 2.7.2.x concerning inlining template functions -are eliminated. Static template data members, template class member -functions, partial specification, and default template arguments are -supported. An instantiation method resembling that used in Borland C++ -(instantiating functions possibly in multiple .o files and using weak -symbols to link correctly) is provided, in addition to other -options. The SGI version of STL is shipped verbatim with libstdc++ -(libstdc++ is included with egcs, separate with gcc-2.8.x). - -@item -@cindex redundant template elimination -@cindex templates: removing redundancy -On ELF platforms (Linux/ELF, Solaris, SVR4), if the GNU linker is used, -duplicated template functions and virtual function tables are eliminated -at link time. - -@item -@cindex repository -@cindex -frepo -The @code{-frepo} flag is supported in egcs (it is not in 2.8.x). -However, because of the previous item, I don't recommend its use on ELF -systems, as the default method is better. - -@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. - -@item -There are many more changes: see @file{http://www.cygnus.com/egcs/c++features.html} for a list. -@end itemize - -Features that are still missing include namespaces and templates as -template arguments, though there is support for the latter feature -in the egcs snapshots (which has not yet made it into a release). - -@node egcs-bug-fixes, egcs-linux, egcs-whats-new, egcs and 2.8.x -@section What was fixed in the latest egcs releases? - -@itemize @bullet - -@item -Add support for Red Hat 5.0 Linux and better support for Linux -systems using glibc2. (1.0.3 was specifically done to fix some -remaining problems detected when building Red Hat 5.1). - -@item -Compatibility with both egcs-1.0 and gcc-2.8 libgcc exception handling -interfaces (see below). - -@item -Various bugfixes in the x86, hppa, mips, and rs6000/ppc backends. - -@item -A few machine independent bugfixes, mostly to fix code generation bugs -when building Linux kernels or glibc. - -@item -Fix a few critical exception handling and template bugs in the C++ -compiler. - -@item -Fix build problems on x86-solaris systems. -@end itemize - -To avoid future compatibility problems, we strongly urge anyone who is -planning on distributing shared libraries that contain C++ code to -upgrade to at least egcs-1.0.1 first (and preferably to 1.0.3). See -@file{http://www.cygnus.com/egcs/egcs-1.0.1.html} for details about the -compatibility issues as well as additional information about the -bugfixes since the egcs-1.0 release. - -@node egcs-linux, egcs-run-both, egcs-bug-fixes, egcs and 2.8.x -@section If I install egcs on Linux, will it overwrite my libraries? - -No. If you build from sources, by default, egcs installs executables in -@code{/usr/local/bin} and libraries in @code{/usr/local/lib}, and you -can change this default if desired (see next section). - -If, however, you install a package (e.g. Debian or Red Hat) that wants -to put egcs in @code{/usr/bin} and @code{/usr/lib}, then yes, you are -replacing your system compiler and C++ library (I don't know if anyone -has provided such packages yet -- proceed with caution). - -@node egcs-run-both, egcs-vs-2.8.x, egcs-linux, egcs and 2.8.x -@section How can I run both egcs and an FSF release of g++ on the same machine? - -The recommended approach is to provide a different argument to the -@code{--prefix} flag when you configure egcs. For example, say -@code{--prefix=/usr/local/egcs} and then, after installation, you -can make symbolic links from @file{/usr/local/egcs/bin} to whereever -you want, for example - -@example -ln -s /usr/local/egcs/bin/gcc /usr/local/bin/egcc -ln -s /usr/local/egcs/bin/g++ /usr/local/bin/eg++ -@end example - -@node egcs-vs-2.8.x, egcs-robustness, egcs-run-both, egcs and 2.8.x -@section What about 2.8.x? How does egcs affect the 2.8.x development? - -2.8.0 has now been released (followed up by 2.8.1), with essentially the -same C++ front end as egcs. - -Bug fixes generated in egcs will be passed to the 2.8.x releases for -inclusion; the reverse is also taking place, though a bug fix may -appear in one before it does in the other. egcs development is currently -proceeding much more quickly than gcc 2.8.x development. However, there -is essentially only one C++ front end, which is shared by the two -distinct compiler back ends (however, since egcs-1.0.3 is newer than -gcc 2.8.1, it has more bug fixes). - -@node egcs-robustness, , egcs-vs-2.8.x, egcs and 2.8.x -@section How robust is egcs? - -While the 'e' stands for 'experimental', egcs has been tested thoroughly -and should be of high quality. The author considers egcs 1.0.3 the -most robust GNU C++ compiler ever produced. - -@node installation, evolution, egcs and 2.8.x, 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.17, released April 27, 1997. -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.9.1, released May 1, 1998. - -Note that if you want to use exceptions on Intel-like platforms and use -gas (e.g. you run Linux), you need binutils version 2.8.1 or newer for -exceptions to work correctly! - -(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. - -Users of egcs or 2.8.x on ELF systems should definitely -use GNU ld (2.8 or later), as it will automatically remove duplicate -instantiations of templates, virtual function tables, or ``outlined'' -copies of inline functions. - -@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++:: -@end menu - -@node version 2.7.x, libstdc++, evolution, evolution -@section What's new in version 2.7.x of gcc/g++ - -[ This section is old now, since 2.8.x/egcs is the new stuff ] The -latest 2.7.x version was 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++ was 2.7.2.1, released August 14, 1996. The libg++ version that -should be used with any 2.7.x gcc/g++ 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++, , 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 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 vast 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. -Note that the SGI version of STL is the one that is included with the -egcs and 2.8.x releases of g++/libstdc++. - -@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). - -As of 2.8.x and egcs-1.0.x, the template implementation has most -of the features specified in the draft standard. Still missing are -template arguments that are themselves templates; however, template -class member functions work, and most of the limitations of the older -g++ versions are fixed. - -I think that given this new implementation, it should not be necessary -for users to mess around with switches like @code{-fno-implicit-templates} -and @code{#pragma} directives; most of the time, the default behavior -will work OK. Users of older versions might want to read on. - -@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.7.2, there are still a few limitations in the template -implementation besides the above (thanks to Jason Merrill for this info): - -@strong{Note}: these problems are eliminated in egcs and in gcc-2.8.x. - -@enumerate 1 -@item -Static data member templates are not supported in compiler versions older -than 2.8.0. 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 - -@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 (again, these problems are fixed in 2.8.0 and egcs): - -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 through 2.7.2.x 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). - -@strong{Note:} this kind of ``guiding declaration'' is not standard and -isn't supported by egcs or gcc-2.8.x, as the standard says that this -declares a ``normal'' @code{min} function which has no relation to -the template function @code{min<int>(int,int)}. But then the new -compilers have no problem inlining template functions. - -@item -Member function templates are always instantiated when their containing -class is. This is wrong (fixed in egcs/2.8). -@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? - -If you want to use the Standard Template Library, do not pass go, -upgrade immediately to gcc-2.8.x or to egcs. The new C++ front end -handles STL very well, and the high-quality implementation of STL -from SGI is included verbatim as part of the libstdc++ class library. - -If for some reason you must use 2.7.2, you can probably get by with -the hacked-up version of the old implementation from HP that is -included with libg++-2.7.2, but it is definitely inferior and has more -problems. Alternatively, g++ 2.7.2.x users might try the following: -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}. - -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 section is for g++ 2.7.2.x users only ] - -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 - -The first really usable exceptions implementations are in 2.8.x and -egcs. With these versions, exceptions are enabled by default; use --fno-exceptions to disable exceptions. - -However, 2.8.1 still has not integrated egcs work that computes an -accurate control flow graph in the presence of exceptions. For this -reason, you will sometimes get bogus warnings when compiling with 2.8.1, --O, and -Wall, about uninitialized variables and the like. - -2.7.2.x has very limited and partially broken support for exceptions. -With that compiler, you must -provide the @code{-fhandle-exceptions} flag to enable exception -handling. In version 2.7.2 and older, exceptions may not work properly -(and you may get odd error messages when compiling) if you turn -on optimization (the @code{-O} flag). If you care about exceptions, -please upgrade to a newer compiler! - -In 2.7.2, 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.} - -Exception handling adds space overhead (the size of the executable -grows); the problem is worse on the ix86 (Intel-like) architecture -than on RISC architectures. The extra exceptions code is generated -in a separate program section and is only paged in if an exception -is thrown, so the cost is in disk, not in RAM or CPU. - -Exception overhead is much lower on ix86 if you use binutils 2.9 or -later, as gas (the GNU assembler) can now compress the information. - -@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. -The new versions (2.8.x/egcs) still lack namespace support, but to help -compile standard programs they make - -@example -using namespace std; -@end example - -a no-op. There is namespace implementation work going on in the egcs -snapshots (but it hasn't been released yet). - -@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 - -Up until recently, there was no really usable exception support. If you -need exceptions, you want gcc-2.8.x or egcs. The implementation works -fairly well. The 2.7.x version was strictly alpha quality and quite -fragile. - -@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 added support for the built-in boolean -type @code{bool}, with constants @code{true} and @code{false}. Run-time -type identification was rudimentary in 2.7.x but is fully supported in -2.8.x, 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. - -[ This paragraph obsoleted by 2.8.x/egcs: ] -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 or later). - -[A full bug list would be very long indeed, so I won't put one here; -the sheer complexity of the C++ language means that every compiler I've -tried has some problems. 2.8.x and egcs are a big improvement] - -@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'. There are two forms -of DWARF, DWARF 1 and DWARF 2. The default is often DWARF 1, which is -not really expressive enough to do C++ correctly. - -Now that we have gdb 4.17, DWARF debugging is finally supported (if -you use gcc 2.8.1 or egcs-1.0.x or newer). - -@cindex stabs -@cindex --with-stabs - -For users of older versions of the tools, 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. - -To specify DWARF 2 output on Unixware, you can give the @code{-ggdb} -switch; alternatively, @code{-gstabs} produces ``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++}. - -Note that in egcs and in gcc-2.8.x, if you do not -specify any libraries the @code{g++} command will only link in -@file{-lstdc++}, so your executable will not be affected by the LGPL -(unless you link in some other LGPLed library: the GNU C library used -on GNU/Linux systems is one such library). - -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 |