"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.14, released March 2, 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).
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.5.2, released November 2, 1994.
(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).
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.
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).
Note: using existing shared libraries (X and libc, for example) works very nicely. Generating shared libraries from g++-compiled code is another matter, generally requiring OS-dependent tricks if it is possible at all. But progress has been made recently.
As of 2.7.0, building C++ shared libraries should work fine on supported platforms (HPUX 9+, IRIX 5+, DEC UNIX (formerly OSF/1), SunOS 4, and all targets using SVR4-style ELF shared libraries).
However, as of libg++ 2.6.2, the libg++ distribution contains some patches to build libg++ as a shared library on some OSes (those listed above). Check the file `README.SHLIB' from that distribution.
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.
In conclusion, I don't see a clear win for either alternative at this point. Take your pick.
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.
If you want to build shared libraries from gcc/g++ output and you are on a Sun, you must not use GNU as, as it cannot do position-independent code correctly yet.
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 GAS distribution has recently 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).
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.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.
Go to the first, previous, next, last section, table of contents.