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, 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.