steve@txsil.lonestar.org (Steve McConnel) (12/31/89)
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. The problem appears to be in the COFF
encapsulation and the output of ld. The compiler and assembler (compiled with
the AT&T compiler) seem to run okay and produce GNU-style .o files, but i
haven't been able to get an executable program yet.
Here's what i've done so far:
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
2) used the follow program as a test (it's rather minimal):
main()
{
write(1, "Hello, world!\n", 14); /* printf() has too much baggage! */
}
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 (?), and
that crt1.o had a relocation to the .init segment of crtn.o that gcc-ld was
not fixing. i wrote a shell script to invoke gcc-ld with crtn.o first, and
a program to twiddle the bits of a.out to fix that relocation. now, the
program prints "Hello, world!\n" before bombing out with a segmentation
fault, but bomb out it still does. Before digging into the code of gcc-ld,
i thought it might be worth asking if anyone else had gotten gcc working on
this setup already.
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. :-( :-( :-(
at least i got emacs working with only a handful of edits! :-) :-) :-)
--
Stephen McConnel
Summer Institute of Linguistics PHONE: 214-709-2418
7500 W. Camp Wisdom Road UUCP: ...!{texbell|convex|pollux}!txsil!steve
Dallas, TX 75236 Internet: steve@txsil.lonestar.orgsef@kithrup.com (Sean Eric Fagan) (01/01/90)
>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.
steve@txsil.lonestar.org (Steve McConnel) (01/02/90)
In article <8912312116.AA12256@ucscc.UCSC.EDU> sef@kithrup.com (Sean Eric Fagan) writes: >>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). i don't trust cvtomf at all -- the only use i make of the Microsoft compiler (cc) is to cross-compile for MSDOS. (the cross-compiler is one of the major reason the department that owns the system bought SCO UNIX rather than any of the alternatives they considered when our 68020 BSD box died last summer.) > . . . > 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. Thanks for the response (thanks also to those who replied via email). I did have to fiddle with the definition of FFS, now that you mention it. It turns out that i was using the tm-i386v.h configuration, and trying to use gas. Silly me. At the moment, I'm using COFF all the way, with the AT&T assembler and linker. This seems to work okay. Of course, as i understand the installation instructions, this also precludes gdb :-(. If i have time, i'll see if the COFF encapsulation works any better with tm-i386gas.h, but at least now i have a working gcc, and can take a look at g++ now. -- Stephen McConnel Summer Institute of Linguistics PHONE: 214-709-2418 7500 W. Camp Wisdom Road UUCP: ...!{texbell|convex|pollux}!txsil!steve Dallas, TX 75236 Internet: steve@txsil.lonestar.org
mea@utu.fi (Matti Aarnio) (01/09/90)
In article <265@txsil.lonestar.org> steve@txsil.lonestar.org (Steve McConnel) writes: >In article <8912312116.AA12256@ucscc.UCSC.EDU> sef@kithrup.com (Sean Eric Fagan) writes: >>>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. ... >Thanks for the response (thanks also to those who replied via email). >I did have to fiddle with the definition of FFS, now that you mention it. >It turns out that i was using the tm-i386v.h configuration, and trying to >use gas. Silly me. At the moment, I'm using COFF all the way, with the >AT&T assembler and linker. This seems to work okay. Of course, as i >understand the installation instructions, this also precludes gdb :-(. If >i have time, i'll see if the COFF encapsulation works any better with >tm-i386gas.h, but at least now i have a working gcc, and can take a look at >g++ now. I am using Gcc 1.36 with AT&T assembler, without any problems. I also get nice gdb informations out of it. Umm.. I did 'make i386v' (or something like it), without modifying any sources on this ISC 2.0.2 ix/386 that I have. Later on I have applied one patch from RMS to avoid fault on statement: float ff = 1e100; :-) (It was in 3dplot program for X-windows, not in my own code) >-- >Stephen McConnel >Dallas, TX 75236 Internet: steve@txsil.lonestar.org /Matti Aarnio <mea@mea.utu.fi> Finnish Academic and Research Network Project (FUNET)