Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: preston@LL.MIT.EDU (Steven Preston)
Newsgroups: comp.sys.next
Subject: Re: REQUEST: How to link g++ objects?
Message-ID: <9103251248.AA08371@LL.MIT.EDU>
Date: 25 Mar 91 17:48:43 GMT
Sender: daemon@tut.cis.ohio-state.edu
Lines: 28

> Come to think of it I know the gnu linker has already been tweaked for
> MACH-O.  Either you haven't set the build switches correctly or you
> have an old version.

Having a Mach-O linker apparently is only half of a solution.  The C++
compiler that comes with NeXT OS2.0 still uses a "collect" step, I was
surprised to find out.  If you specify the -v flag, you can see the
collect step.  cc++ does these steps, when building an executable
(with temporary filenames in place of t.R, t.S, t.O)

/bin/ld -r -o t.R -lcrt0.o t.o -lc++ -lsys_s
/lib/collect -o t.S t.R
/bin/as t.S -o t.O
/bin/ld -o t t.R t.O

It is NOT one of the collect's that comes with g++, although the above
sequence is what the collect2 program does, except that collect2 uses
nm to generate a list of names in the t.R, which it searches for
static constructors and destructors.  I presume /lib/collect searches
the symbol table of t.R directly, rather than use nm.

The situation would be much better if cc++ put the static ctors and
dtors into a __CPLUSPLUS segment, for instance, and rewrite __main(),
which is called automatically by main(), to look in that segment.
This is similar to the way Objective-C classes are located and linked
together at startup.
--
Steve Preston