menges@unc.UUCP (John Menges) (11/19/86)
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.
4. Fixed the '-o', 'test', and 'signal declaration' problems in the makefile
and incl/signal.h .
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.
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.
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.jon@oddhack.Caltech.Edu (Jon Leech) (11/20/86)
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 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> - remove the 'Task' target from lib/mk/makefile - 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. - <osfcn.h> contains a line extern int acct (const har *); make the obvious change to 'char *'. - <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. - 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. 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 __@/