Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!kithrup.com!sef From: sef@kithrup.com (Sean Eric Fagan) Newsgroups: gnu.gcc.bug Subject: porting GCC to SCO UNIX V/386 (3.2) Message-ID: <8912312116.AA12256@ucscc.UCSC.EDU> Date: 31 Dec 89 21:12:29 GMT Sender: daemon@tut.cis.ohio-state.edu Distribution: gnu Organization: GNUs Not Usenet Lines: 66 >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 , but I'm not sure which one. I sent RMS off a note about it, saying that I thought it was happening because of , 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.