geoffc@zebedee%tharr.uucp (Geoffrey Coan) (05/11/91)
I tried sending this to CvW but it disappeared into the newsnet ether so can anyone else help .... ? I've been recently trying to install c68 v3 under minix ST 1.5.10.3 and I'm having some problems. I unpacked the c68 v3 sources and patches 1 & 2 and applied them all OK. I also unpacked the makefile.uue supplied with patch 2 and I did 'make ack' to make the version of c68 to run with the ack libraries and linker (I think this bit was right ...). The make went OK and I ended up with a c68 module OK which I then tried to use as in: /usr/lib/cpp file.c >file.i c68 file.i file.s .. etc the resultant file.s was empty and only contained the bss, data, text, etc section labels. One article on comp.os.minix earlier suggested adding -DICODE to the make - I did this and when running c68 with -Qicode I just got an empty icode file. I compiled the new cc.c under ack but whenever I run it I get 'internal error' (either ack or c68 mode) - I don't know about this one either ! Finally, I have all the lib68k and liback .s files - what do I do with them ? I presume that they go to make up some sort of new library (is this libc68.a ?) or am I even more off track. Help ! Thanks, Geoffrey Coan -- ------------------------------------------------------------------------------- are you ready to SKYDIVE ?? Geoffrey Coan well all right then, if you say so ... ..!ukc!axion!tharr!zebedee!geoffc <- UUCP'd from my ST via tharr; *free* UK public access to Usenet 0234 720202 ->
templon@copper.ucs.indiana.edu (jeffrey templon) (05/12/91)
In article <2130022@zebedee%tharr.uucp> geoffc.zebedee@tharr.uucp writes: >the resultant file.s was empty and only contained the bss, data, text, etc >section labels. One article on comp.os.minix earlier suggested adding >-DICODE to the make - I did this and when running c68 with -Qicode I just >got an empty icode file. > I outlined the solution to this problem about a month ago in one of my "hack report" articles. It was for MacMinix but the same thing applies for Minix ST. You can get the article off listserv@vm1 by using "hack report" as the search field. I would repost but it has already expired on bronze. The basic problem is that ACK does not report errors like it should. ACK cannot handle the floating point code in the c68 source code; stock ACK does not support floating point (fp). It merrily chugs along, though, and makes a c68 executable. However the c68 executable which is produced in this way is drain-bamaged beyond recognition. This results in your "almost empty" .s files. You have to bootstrap the compiler somehow. CvW gave me several suggestions on how to do this. The most useful one, for me, was to find an old comp.os.minix article which had a c68 BINARY uuencoded. You can get this by searching listserv@vm1 -- use "68000 C compiler" as search key. Once you get this, you compile your NEW c68 source (version III) with the OLD binary (I think it is from version II). This will give you a working c68 version III. When I got to this stage, I re-compiled vIII with the vII-produced vIII executable, just in case. >Finally, I have all the lib68k and liback .s files - what do I do with them ? >I presume that they go to make up some sort of new library (is this libc68.a?) >or am I even more off track. > There is probably a more "correct" thing to do, but what *I* did was just shove them into libc.a using the ar command. I did assemble them into .o files first. JT
Christoph van Wuellen <HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu> (05/13/91)
'empty' .s files have a simple reason: your ACK-produced c68 binary chokes on the first FP instruction and dies silently (!) then. C.v.W>