🚀 go-pugleaf

>Has anyone successfully ported gcc to SCO UNIX V/386?  i've spent this week
>working on it, learning more about COFF (and a.out) format than i ever wanted
>to know, but still nothing works.  

Yes, I have (and also moved the resultant binary to my xenix machine).  As
you point out, I compiled it with the AT&T compiler (rcc), for various
reasons (didn't trust cvtomf at the time, mostly).

>1) modified robotussin to handle some oddities in the SCO UNIX /lib/libc.a and
>   /lib/crt*.o files.  (two .data segments in many of the object files in
>   /lib/libc.a, and an .init segment in crt1.o and crtn.o that apparently
>   contains text.)  built /usr/local/lib/gnu/libc.a and /usr/local/lib/gcc-*.o

This is because of cvtomf, which turns an OMF file into a COFF file, turns
either the BSS or CONST segment into another .data (I *think* it's the
CONST, but I'm not sure).

>3) when this bombed out with a segmentation fault immediately, i dug into the
>   a.out's and found that the SCO linker was putting crtn.o first (?), 

With the SCO C compiler (/bin/cc), you can look at the arguments to the
passes with the '-d' or '-z' flags ('-d' displays and executes, '-z' shows
but does *not* execute).

This is what the compiler driver tries to execute for a COFF binary:

	/bin/ld /lib/crt1.o /lib/crt1.o t.o -o a.out -lc /lib/crtn.o

so, as you can see, we're putting crtn.o *after* everything.  With the
exception of the double'd crt1.o (please don't ask about that; it's a rather
long, boring, and painful story 8-)), and the lack of a gnulibc, this is the
same as what gcc does.

>next week, i have to resume working on my normal projects, so this will drop
>to a rather low priority back-burner effort...  pity, i was really hoping to
>get g++ going as well as gcc. :-( :-( :-(

It took me about 4 hours to get gcc-1.36 running under SCO UNIX; a lot of
this was compile time, but, the first time through, I babysat it and made
sure everything worked properly.  Something else you may have run into, but
didn't mention, was that one of the sys files (/usr/include/sys/???.h)
defines FFS:  in this case, it means 'Fast File System,' but gcc wants the
same symbol for Find-First-Set-bit.  Anyway, I *think* it's one of the files
in <sys/s5>, but I'm not sure which one.  I sent RMS off a note about it,
saying that I thought it was happening because of <sys/param.h>, but it's
been a while, so I'm not sure.

I got g++ (1.35, I think) working (actually a friend and I did; took us two
days), with the exception of the streams, which don't work (somebody has
posted patches to make it work, but which I haven't tested).  I think what
we ended up doing was modifying the startup routine to call __ain instead of
_main, and wrote an __ain which called the appropriate constructors and
destructors.  Ask cbcscmrs@gaia.csun.edu (Mike Stump) for more information,
as I didn't do it.

>at least i got emacs working with only a handful of edits! :-) :-) :-)

Using all of the neato SCO UNIX features?  I've been told that job control
should be working by the next release (3.2.2?), so it might be good to build
it with that.  Did you get it to use sockets and what not?  Tell more! 8-)

Sean.
-----
Sean Eric Fagan
sef@kithrup.COM	
This is my machine, so I can say what I want.