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 http://www.cygnus.com/misc/g++FAQ_toc.html.
Please send updates and corrections to the FAQ to
jbuck@synopsys.com. Please do not use me as a resource
to get your questions answered; that's what gnu.g++.help is for and I
don't have the time to support the net's use of g++.
Many FAQs, including this one, are available on the archive site
"rtfm.mit.edu"; see
ftp://rtfm.mit.edu/pub/usenet/news.answers.
This FAQ may be found in the subdirectory g++-FAQ.
This FAQ is intended to supplement, not replace, Marshall Cline's excellent FAQ for the C++ language and for the newsgroup 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 ftp://rtfm.mit.edu/pub/usenet/comp.lang.c++, or in HTML form at http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/.
This section is intended to describe more recent changes to g++, libg++, and such. Some things in this section will eventually move elsewhere.
News: as I write this (late February 1996) the gateway connecting the bug-g++ mailing list and the gnu.g++.bug newsgroup is broken. Please mail, do not post bug reports.
The current version of gcc/g++ is 2.7.2.1, released August 14, 1996. The current version of libg++ is 2.7.2, released July 4, 1996.
Note that gcc 2.7.2.1 just consists of several small patches to gcc-2.7.2. The release is mainly intended to fix platform-specific bugs and does not affect the C++ "front end" of the compiler (the part that parses your C++ code).
The 2.7.x releases represent a great deal of work on the part of the g++ maintainers to fix outstanding bugs and move the compiler closer to the current ANSI/ISO standards committee's working paper, including supporting many of the new features that have been added to the language. I recommend that everyone read the NEWS file contained in the distribution (and that system administrators make the file available to their users). I've borrowed liberally from this file here.
If any features seem unfamiliar, you will probably want to look at the recently-released public review copy of the C++ Working Paper:
Here are the main points:
-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.
-frtti.
This support is still in alpha; one major restriction is that any file
compiled with -frtti must include <typeinfo> (not
typeinfo.h as the NEWS file says).
Also, all C++ code you link with (including libg++) has to be built with
-frtti, so it's still tricky to use.
a ? b : c = 1
has changed from
(a ? b : c) = 1 to a ? b : (c = 1). This is a new C/C++
incompatibility brought to you by the ANSI/ISO standards committee.
-ansi or
-foperator-names to enable them.
explicit keyword is now supported. explicit is used to mark
constructors and type conversion operators that should not be used
implicitly.
inline template class foo<int>;
can be used to emit only the vtable
for a template class.
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 (See section What are the rules for shipping code built with g++ and libg++?).
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 (see See section Does g++ support the 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 latest "2.x" version of gcc/g++ is 2.7.2.1, released August 14, 1996. The latest version of libg++ is 2.7.2, released July 4, 1996.
Don't use 2.5.x, with x less than 5, for C++ code; there were some serious bugs that didn't have easy workarounds. 2.5.8 is the most solid 2.5.x release. 2.6.3 is the most solid 2.6.x release.
For some non-Unix platforms, the latest port of gcc may be an earlier version (2.5.8, 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.5.x (for the latest x you can find) with gcc version 2.5.8.
The latest "1.x" version of gcc is 1.42, and the latest "1.x" version of g++ is 1.42.0. While gcc 1.42 is quite usable for C programs, I recommend against using g++ 1.x except in special circumstances (and I can't think of any such circumstances).
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).
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.
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++.
For more information about ordering from the FSF, contact gnu@prep.ai.mit.edu, phone (617) 542-5942 or anonymous ftp 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").
Here is a list of anonymous FTP archive sites for GNU software. If no directory is given, look in `/pub/gnu'.
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
The "official site" is prep.ai.mit.edu, but your transfer will probably go faster if you use one of the above machines.
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.
[ Warning: this information about UUCP access to UUNET and Ohio State is about five years old; I'm not sure if these services still exist. ]
UUNET customers can get GNU sources from UUNET via UUCP. UUCP-only sites can get GNU sources by "anonymous UUCP" from site "osu-cis" at Ohio State University. You pay for the long-distance call to OSU; the price isn't too bad on weekends at 9600 bps. Send mail to uucp@cis.ohio-state.edu or osu-cis!uucp for more information.
OSU lines are often busy. If you're in the USA, and are willing to spend more money, you can get sources via UUCP from UUNET using their 900 number: 1-900-GOT-SRCS (900 numbers don't work internationally). You will be billed $0.50/minute by your phone company.
Don't forget to retrieve libg++ as well!
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 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.
"Sun took the C compiler out of Solaris 2.x. Am I stuck?"
You'll need to get prebuilt binaries from someone.
It used to be that you could get GCC binaries from prep.ai.mit.edu; these are no longer there.
The WWW site http://smc.vnet.net/solaris_2.5.html contains various GNU and freeware programs for Solaris2.5 running on the sparc. These are packaged to enable easy installation using the Solaris "pkgadd" utility. These include GNU emacs, gcc, gdb, perl, and others. These versions are more recent than the binaries at "prep" (gcc 2.7.2 and libg++ 2.7.1 are there).
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 http://www.cygnus.com/misc/gnu-win32/ on the WWW, or the anonymous FTP directory ftp://ftp.cygnus.com/pub/gnu-win32/.
The standard gcc/g++ distribution includes VMS support. 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 are available by FTP from ftp://mango.rsmas.miami.edu/pub/VMS-gcc/.
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 ftp://ftp.coast.net/SimTel/vendors/djgpp/ or, for a complete list, see http://www.delorie.com/djgpp/getting.html.
The latest version of DJGPP is 2.00. See 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: comp.os.msdos.djgpp.
For information on Amiga ports of gcc/g++, retrieve the file
ftp://prep.ai.mit.edu/pub/gnu/MicrosPorts/Amiga
or write
to Markus M. Wild <wild@nessie.cs.id.ethz.ch>, who I hope won't be too upset
that I mentioned his name here.
A port of gcc to the Atari ST can be found at
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
comp.sys.atari.st for more information.
There are two different ports of gcc to OS/2, the so-called EMX port (which also runs on MS-DOS), and a port called "gcc/2". The latter port is no longer supported, since the EMX port includes all of its functionality. The EMX port's C library attempts to provide a Unix-like environment. For more information ask around on `comp.os.os2.programmer.misc'.
The EMX port is available by FTP from
ftp://ftp.uni-stuttgart.de/pub/systems/os2/emx-0.9a ftp://src.doc.ic.ac.uk/pub/packages/os2/unix/emx09a ftp://ftp.informatik.tu-muenchen.de/pub/comp/os/os2/devtools/emx+gcc
Eberhard Mattes did the EMX port. His address is mattes@azu.informatik.uni-stuttgart.de.
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
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.
"I keep hearing people talking about g++ 2.7.2 (or some other number starting with 2), but the latest version I can find is g++ 1.42. Where is it?"
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."
"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?"
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.
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.
First off, you'll want libg++ as you can do almost nothing without it (unless you replace it with some other class library).
Second, depending on your platform, you may need "GAS", the GNU assembler, or the GNU linker (see next question).
Finally, while it is not required, you'll almost certainly want the GNU debugger, gdb. The latest version is 4.15.1, released November 4, 1995. Other debuggers (like dbx, for example) will normally not be able to understand at least some of the debug information produced by g++.
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).
If you have experience with AT&T's "cfront", this function is performed there by programs named "patch" or "munch". With GNU C++, it is performed either by the GNU linker or by a program known as "collect". The collect program is part of the gcc-2.x distribution; you can obtain the GNU linker separately as part of the "binutils" package. The latest version of binutils is 2.7, released July 10, 1996; 2.6 is in common use and works well.
(To be technical, it's "collect2"; there were originally several alternative versions of collect, and this is the one that survived).
There are advantages and disadvantages to either choice.
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.
If your native linker supports shared libraries, you can use shared libraries with collect. This used to be a strong reason 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).
See section How do I build shared libraries with g++?
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.
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
--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.
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 --enable-shared option to the configure
program. When compiling your own code for shared libraries you
generally
must use the -fPIC flag to get position-independent code.
Check the file `README.SHLIB' from the libg++ distribution for more about making and using shared libraries.
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 ftp://ftp.cygnus.com/pub/g++/libg++-2.7.2-hppa-gcc-fix.
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: 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.
If you're running NetBSD or BSDI, the Cygnus repo patch is not quite correct. Tim Liddelow has made an alternate version available at ftp://ftp.cst.com.au/pub/gcc-2.7.2-repo-bsd.gz.
After you've applied the patch, the -frepo flag will enable the
repository mechanism. The flag works much like the existing
-fno-implicit-templates flag, except that auxiliary files, with
an `.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 `foo.C' contains template definitions corresponding to template declarations in `foo.h'.
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."
"The -frepo won't expand templated friend functions!"
This is a known bug; currently you'll have to explicitly instantiate
friend functions when using -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
-D'MESSAGE="hello there"'
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.
At this point in time, no. 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.
"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?"
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 (See section Should I use the GNU linker, or should I use "collect"?).
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.
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
make install-collect2
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).
"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
as: "/usr/tmp/cca14605.s", line 8: error: statement syntax as: "/usr/tmp/cca14605.s", line 14: error: statement syntax
(on a Sun, different on other platforms). The important thing is that the errors come out at the link step, not when a C++ file is being compiled.
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.
"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 `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 --prefix option to install gcc somewhere
other than `/usr/local', you must use the same value for
--prefix when installing libg++, or else g++ will not be able
to find libg++.
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 ftp://ftp.cygnus.com//pub/g++/libg++-2.6.2-fix.gz.
size_t!
"I did all that, and I'm still having problems with disagreeing
definitions of size_t, SIZE_TYPE, and the type of functions like
strlen."
The problem may be that you have an old version of `_G_config.h' lying around. As of libg++ version 2.4, `_G_config.h', since it is platform-specific, is inserted into a different directory; most include files are in `$prefix/lib/g++-include', but this file now lives in `$prefix/$arch/include'. If, after upgrading your libg++, you find that there is an old copy of `_G_config.h' left around, remove it, otherwise g++ will find the old one first.
"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++?"
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.
I recommend against using the -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 --prefix flag when configuring gcc. Use a
different value of --prefix for each gcc version. Use the
same value of --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 --prefix to
`/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
`/usr/local/bin/gcc' and `/usr/local/bin/g++'.
"I've downloaded the latest g++ and libg++ and I'm trying to install them on Linux, and I'm having lots of problems."
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 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 ftp://www.mrc-apu.cam.ac.uk/pub/linux/GCC-FAQ.html, the Linux GCC FAQ (though it may be a bit out of date; the Linux community moves quickly).
"When I try to compile the traditional Hello, world program on Linux, the compiler can't find `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:
ln -s /usr/lib/g++-include /usr/include/g++
"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.
gcc-2.7.0 implements the new ANSI/ISO rule on the scope of variables declared in for loops.
for (int i = 1; i <= 10; i++) {
// do something here
}
foo(i);
In the above example, most existing C++ compilers would pass the
value 11 to the function foo. In gcc 2.7 and in the ANSI/ISO
working paper, the scope of 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 -fno-for-scope that causes the old rule to be used.
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 -ffor-scope flag under 2.7.1 and 2.7.2 gives the 2.7.0 behavior.
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.
The default constructor for the template 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
os_pair () : first (T1 ()), second (T2 ()) {}
to just
os_pair () {}
Once this is done, ObjectSpace<STL> works fairly well.
"When I use -Wall (or -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:
int Foo::bar(int arg) { return 0; }
will give a warning for the unused parameter arg. To suppress
the warning write
int Foo::bar(int) { return 0; }
"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:
switch ( i ) {
case 1:
Object obj(0);
...
break;
case 2:
...
break;
}
The reason is that 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 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:
case 1:
{
Object obj(0);
...
break;
}
A g++-compatible demangler named c++filt can be found in the
`binutils' distribution. This distribution (which also contains
the GNU linker) can be found at any GNU archive site.
As of version 2.7.0, c++filt is included with gcc and is
installed automatically. Even better, it is used by the collect
linker, so you don't see mangled symbols anymore (except on platforms
that use neither collect nor the GNU linker, like Solaris).
"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
class Foo {
...
void method();
static int bar;
};
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 both method() and bar in some source file. According to the draft ANSI standard, you must supply an initializer, such as
int Foo::bar = 0;
in one (and only one) source file.
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).
"I think I have found a bug in g++, but I'm not sure. How do I know, and who should I tell?"
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 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 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.
First, mail your bug report to "bug-g++@prep.ai.mit.edu". You may also post to 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.
News: as I write this (late February 1996) the gateway connecting the bug-g++ mailing list and the gnu.g++.bug newsgroup is (temporarily?) broken. Please mail, do not post bug reports.
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.
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 ftp://research.att.com/dist/stdc++/WP. For HTML and ASCII versions, see ftp://ftp.cygnus.com/pub/g++. On the World Wide Web, see http://www.cygnus.com/misc/wp/.
An older standard reference is "The Annotated C++ Reference Manual", by Ellis and Stroustrup (copyright 1990, ISBN #0-201-51459-1). This is what they're talking about on the net when they refer to "the ARM". But you should know that changes have been made to the language since then.
The ANSI/ISO C++ standards committee have adopted some chan