mo@seismo.CSS.GOV (Mike O'Dell) (12/15/86)
I am trying to get C++ v1.1 up on a SUN3 running release 3.0. I have gotten the "scratch" system to run, but am having all kinds of mismatches between the "incl" header files and what is in the header files on the SUN (/usr/include/sys/signal.h confilicts in main.c of cfront, for example). Has anyone else gotten all this put together sucessfully? I would appreciate any pointers I can get, no pun intended, short of simply sitting down and reverse engineering all the stuff to see what is intended and redoing it. -Mike
menges@unc.UUCP (John Menges) (12/16/86)
In article <43008@beno.seismo.CSS.GOV> mo@seismo.CSS.GOV (Mike O'Dell) writes: >I am trying to get C++ v1.1 up on a SUN3 >running release 3.0. I have gotten the >"scratch" system to run, but am having all >kinds of mismatches between the "incl" >header files and what is in the header files >on the SUN (/usr/include/sys/signal.h confilicts >in main.c of cfront, for example). > >Has anyone else gotten all this put together >sucessfully? I would appreciate any pointers >I can get, no pun intended, short of simply >sitting down and reverse engineering all the >stuff to see what is intended and redoing it. > > -Mike Yes. I posted a similar query in this newsgroup recently, and Jon Leech at Caltech came to my rescue. Below are my original request and his response, with my current comments in [] brackets. Following that is an orderly summary of what needs to be done. By the way, Jon, thanks a lot, you were a big help. We now have C++ version 1.1 installed on our Vaxes, Sun-2s, and Sun-3s. If the instructions below don't work, contact me by email and I'll try to help. My original article: --------------------------------------------------------------------------- I am trying to port C++ version 1.1 to our Suns, initally to our Sun-2s running version 3.0 of UNIX, and am having some difficulties. I'd appreciate help from anyone who has done this before or who can help me figgure out what's going wrong. Even if you can't help, I'd be interested in knowing if anyone has version 1.1 up on any Sun anywhere. Here's what I've done so far: 1. Installed C++ version 1.1 on a Vax (successfully). 2. Removed all the *..c and *..o files from the 'scratch' directory and its sub-directories. 3. Ran 'bsd.fix' to fix up the main makefile and incl/* files for BSD. [I actually did this before step 1, as our Vaxes run 4.2bsd.] 4. Fixed the '-o', 'test', and 'signal declaration' problems in the makefile and incl/signal.h . [I did these before #1 also, for the same reason. Here are context diffs of the various fixes: The munch -o problem: (Thanks to Steve Shumway at Duke for this fix.) (Other people solved this in different ways.) --- CC Tue Dec 16 10:36:38 1986 *************** *** 164,169 done else echo "$ccC $P $X $LIBRARY" 1>&2 $ccC $P -c $X >__err # compile, no load EE=$? for A in $MVLIST --- 164,192 ----- done else echo "$ccC $P $X $LIBRARY" 1>&2 + # + # Remove "-o arg" from CC argument string (X) if -c used. + NX= skipnext= + for A in $X + do + if test $skipnext + then + skipnext= + continue + fi + if test $A = -o + then + skipnext=true + else + NX="$NX $A" + fi + done + X=$NX $ccC $P -c $X >__err # compile, no load EE=$? for A in $MVLIST The 'test' problem: --- CC Tue Dec 16 10:58:56 1986 *************** *** 219,225 fi esac ! if test "$R" -a ! "$PLUSI" then rm $C fi --- 219,225 ----- fi esac ! if test "$R" != "" -a "$PLUSI" = "" then rm $C fi --- signal.h Wed Dec 10 16:13:07 1986 *************** *** 7,13 extern int (*sigset (int, PF))(); extern int (*ssignal(int, PF))(); ! extern int (*signal (int, PF))(); extern int gsignal (int); extern int kill (int, int); --- 7,16 ----- extern int (*sigset (int, PF))(); extern int (*ssignal(int, PF))(); ! ! extern int (*signal ())(); ! ! /* extern int (*signal (int, PF))(); */ extern int gsignal (int); extern int kill (int, int); ] 5. Added '-Uvax -Dsun' to the CC commands in the 'fillscratch' target of the main makefile, so that the conditional code (e.g., in src/size.c) would be compiled for the Sun instead of the Vax. 6. Ran 'make fillscratch' on the Vax. 7. Matched the FILE structure in scratch/src/*..c against /usr/include/stdio.h on the Sun - looks ok. 8. Copied the whole source, including the newly-created *..c files in the 'scratch' directory to a Sun-2. 9. Ran 'make scratch' (successfully). 10. Installed CC and the bootstrap cfront and munch in my execution path. [And libC.a in /usr/lib.] 11. Ran 'make' in the main directory, with the following result: --------------------------------------------------------------------------- % make cd lib/mk; /bin/make CC=CC CCFLAGS="-O -DBSD" BSD=1 CC -O -DBSD -I../complex -c ../complex/abs.c CC ../complex/abs.c: "/usr/include/CC/math.h", line 7: internal <<cfront 05/20/86>> error: 470768-> base type::dcl_print( 102) 1 error cc -c -O -lC *** Error code 1 Stop. *** Error code 1 Stop. --------------------------------------------------------------------------- 12. Changed "int BI_IN_WORD = 16 ;" to "int BI_IN_WORD = 32 ;", and "int SZ_WORD = 2 ;" to "int SZ_WORD = 4 ;", to correspond with numbers quoted by Jonathan P. Leech of Caltech in an earlier news article, rather than the numbers indicated in the C++ version 1.1 source for Suns. [Note: this is in src/size.h, and this should be done before 'make fillscratch'. I'm running with the 32/4 sizes, but I'm not sure this is correct.] 13. Re-ran "make scratch", re-installed the bootstrap cfront and munch in my path. 14. Re-ran "make", with the same result as in 11 above. --------------------------------------------------------------------------- Here's Jon's response: In article <256@unc.unc.UUCP> menges@unc.UUCP (John Menges) writes: >11. Ran 'make' in the main directory, with the following result: > ... >CC -O -DBSD -I../complex -c ../complex/abs.c >CC ../complex/abs.c: >"/usr/include/CC/math.h", line 7: internal <<cfront 05/20/86>> error: 470768-> base type::dcl_print( 102) >1 error Me too. Try editing <math.h> and moving the declarations of 'atof' and 'frexp' onto two separate lines as follows: /* @(#) math.h 1.4 1/27/86 17:46:49 */ /*ident "@(#)cfront:incl/math.h 1.4"*/ #ifndef _POLY9 extern int errno, signgam; extern int abs (int); extern double atof(const char*); extern double frexp(double, int*); ...etc [This does indeed work.] I don't know why this works, but it does. There are a few other things I had to do: - define MAXFLOAT in <math.h> [I did this too.] - remove the 'Task' target from lib/mk/makefile [And this. Does anyone have Sun-2 or Sun-3 task libraries?] - add the '-P' option to the CC shell script variable $CPLUS (preprocessor options): CPLUS="-Dc_plusplus=1 -P" for some reason cpp was generating files containing lines like # 1 "file.h" 1 (note the extra trailing line number), which made BOTH cfront and cc complain. The -P cpp option removes line directives, which will have bad implications for debugging, but at least the code compiles now. [I did not encounter the above problem, so I did not add the "-P" option. it does indeed make debugging difficult if the "-P" option is used.] - <osfcn.h> contains a line extern int acct (const har *); make the obvious change to 'char *'. [I did this.] - <signal.h> includes <sys/signal.h>, which comes from /usr/include/sys because there is none in /usr/include/CC/sys. A conflicting prototype for signal() results. Fixed by copying the C <sys/signal.h> to the CC version and correcting the signal() prototype. [I believe this is too drastic. I just made the change noted above in #4.] - Finally, in a number of places in src/main.c, and in lib/new/_vec.c:_vec_delete(), the code calls a pointer-to-function without dreferencing it. This works on PCC based compilers but not on Amdahl UTS (this is not a Sun problem). I don't know whether this usage is 'legal' now, but it ought to be fixed to dereference the function pointer in any case. [I haven't done this.] There were a few other minor things while getting C++ up on various systems; if I have time (unlikely soon), I'll try to post a summary similar to the one I did for Release 1.0 last spring. The stuff above covers most of the problems. I ``fortunately'' have access to quite a wide range of machines - Sun, 4.[23] BSD Vax, 3B20, IBM 4381/UTS, HP 9000/320, ELXSI and so get to find all sorts of obscure problems when porting C++ around. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/ --------------------------------------------------------------------------- In summary, do the following: On a Vax running 4.2bsd: 1. Run bsd.fix. 2. Fix -o, test, signal.h, size.h (?), math.h, osfcn.h, and Task problems. 3. Remove *..c and *..o files from scratch sub-directories. 4. Add -Uvax -Dsun to the fillscratch target CC commands in the main makefile. 5. Run 'make fillscratch'. 6. Copy the whole source, including the newly-created *..c files in the 'scratch' directory to a Sun (Sun-2 or Sun-3). On the Sun: 7. Run 'make scratch'. 8. Install CC and the bootstrap cfront and munch in your execution path, and the libC.a library in your 'cc' library search path (/usr/lib/libC.a). 9. Run 'make' in the main directory, creating new 'cfront' and 'munch' programs. 10. Install the new cfront, munch, and libC.a. 11. Run 'make' in the main directory to test CC.