Should I use the GNU linker, or should I use "collect"?
=======================================================

   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.

   Advantages of the 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).

   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.

   Advantages of collect:

   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, Linux/ELF 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.