Forrie,
I did most of that stuff about a year ago, so my memory may be a little
hazy, but I'll see what I can remember.  Also I had to jump through a
few hoops you won't since I was creating header files as I went.

Anyway, after figuring out enough of the executable file format and
a little about how the shared library file was laid out, I decided that
it would be easier to get gnu ld running on the Suns than to make the
assembler output the format expected by the ld included in the Foundation
Set.

It appears that I did  the assembler first though.  That wasn't too
hard to get running.  The trickiest part was to make sure that a few
routines (atof comes to mind; come to think of it, I may not have
ever got that one set up in the cross-development environment) did
the right things.  That is that they produced output suitable for
the 3b1 rather than for the host machine.  Just now looking over 
the code to gas, I noticed that I used the generic 68k format but
that there doesn't appear to be much of anything else I needed to
do.  I did for some unknown reason have to play around with the
comment handling, but don't really remember why or exactly what
I needed to do.

There are two linkers in the GNU stuff, an old one thats about 6000 lines
in one file and a newer one that's supposed to be able to handle a
real plethora of input and output formats.  Since I didn't have a number
of header files that the new one expected, I decided to hack up the old
one to take a.out .o files and produce COFF executables.  I figured that
I could create a number of .o files with just the defs for the shared
library entry points, put them in libc.a and let the linker resolve
them.  In your case, you'll probably be able to use the new linker
which I think is in the binutils.  I expect it'll minimize the hacking
you'll need to do to the assembler and still let you use all the
libraries that you have.  Unfortunately, I didn't get far enough into
it to be of much help on how to set it up.

One thing that did cause me a little problem with the linker and the
C preprocessor was their symbol tables.  The authors declared global
arrays for the hash tables but didn't initialize them.  Technically,
they don't have to, since static storage is supposed to be initialized
by the run-time system.  For some reason it wasn't all initialized on
my 7300.  It may have been a bug in the COFF header I produced, but
I found it easiest to just add a little routine to set the array of
pointers to NULL.  BTW the symptom of the problem, was core dumps
that were dependent on the names of symbols.

On gcc, the main things had to do with the cross-compiler nature
of things.  gcc likes to generate some calls to routines that do
long and float ops.   The way they set it up is to create a thing
called gnulib using the native compiler to generate the appropriate
machine sequences for these things.  This, of course, wouldn't work
in a cross-development environment.  So I wrote versions myself
in assembler, but I've found out since that the shared library has
these things under different names.  The other thing I did was to
create a small shell script that called gcc telling it where the 
other programs were, not to use the standard libraries for things,
a libc.a to link in and at what address to  put the executable.
It's a little sloppy in that it still specifies the libraries even
if you're only generating .o files, but it was good enough.  Here it
is broken into separate lines for readability:

/home/faculty/stuart/unixpc/bin/gcc -B/home/faculty/stuart/unixpc/bin/gcc-
    -T 80000 -nostdlib /home/faculty/stuart/unixpc/crt0.o $*
    /home/faculty/stuart/unixpc/libc.a

I hear that newer versions (I worked on 1.40) are organized so that
building cross-compilers are easier, but I haven't had a chance to
look into them myself (the latest version is at around 2.4.5 or 2.5.2
I seem to remember).

I would suggest getting the assembler working first Once it's generating
reasonable looking code (look at it with od), move on to ld.  When
that's working, you should be able to download executables and run
them.  Once that's working, get gcc going.  When that is finished,
then compile it all with itself and download the new native 3b1 executables.
When I had the cross-development envvironment running, the hardest
parts of getting native tools were things like the afore mentioned
static initialization thing.

On the whole, the GNU stuff is written well from a portability and
cross-development point of view.  They seem to have done a good job,
for instance, avoiding problems with byte-sex though you may be bitten
by things that didn't get me.  Looking at the dates on my files, it
looks like it took me about a month or two of spare time (with a little
extra time around Christmas) to get the cross-development stuff running
and then a few more weeks of spare time getting the native versions
up.  Since then, we've gotten hooked up to the net and I have access
to some things that would have made it easier, but it was kind of fun
hacking in sort of a "desert island" mode.

Well, as usual I've been a bit long winded.  I hope this helps and if
you have any questions, I'll do my best to pass on what I know about
it.

Hope this helps,
Brian L. Stuart
stuart@mathcs.rhodes.edu