Path: utzoo!telly!ddsw1!mcdchg!rutgers!tut.cis.ohio-state.edu!UUNET.UU.NET!munnari!ditmelb.oz.au!SMART From: munnari!ditmelb.oz.au!SMART@UUNET.UU.NET (Robert Smart) Newsgroups: gnu.gcc.bug Subject: Porting GNU CC 1.30 to VMS Message-ID: <8811250243.AA27364@uunet.UU.NET> Date: 25 Nov 88 03:01:00 GMT Sender: daemon@tut.cis.ohio-state.edu Distribution: gnu Organization: GNUs Not Usenet Lines: 80 I wanted to enhance GNU CC to understand the C$INCLUDE logical that the VMS C compiler knows about. Actually I wanted it to work better than VMS C, so that it would understand things like "../h/x.h". I had recently received 1.30 and installed it on our Sun, so I thought: silly to enhance 1.22 on VMS, I'll just get 1.30 going under VMS then attack that. First problem was unknown symbols GCC_INCLUDE_DIR and GPLUSPLUS_INCLUDE_DIR. I just gave them an appropriate looking definition under ifdef VMS. It seemed that they were only used for calculating a length of the initial part of a file name. The second problem was with the new bison. I know now that I should have just copied the unix *.tab.c to *_TAB.C on VMS, but I didn't know that then. So I got the new bison running, but it mysteriously put a byte of all ones in the middle of the file. I had to make the following change to output.c: ************ File C:[SMART.GNU.BISON]OUTPUT.C;2 1281 if( c!=EOF) putc(c, ftable); 1282 c = getc(fpars); ****** File C:[SMART.GNU.BISON]OUTPUT.C;1 1281 putc(c, ftable); 1282 c = getc(fpars); ************ I wonder why this isn't a problem in unix? I might say that GCC gave an unhelpful error message for the bad character. I tried compiling with VMS C and got the obvious error message: illegal character on line etc. There were various minor problems with the make*.com files. Source files had changed their names, or new ones added. I now had problems assembling the output from c-parse_tab.c. I decided I'd better create the new assembler. GCC 1.22 had an immediate problem in that there was no varargs.h -- I put the one from the 1.30 distribution in the include directory. The make-gas.com file also required error=as_fatal added to the /DEFINEs for xrealloc, xmalloc, hash and vms. But that didn't make any difference. So I looked at the .s file and it seemed to be corrupted. So I decided that gcc 1.22 couldn't handle it. So I went over to the Sun to make a 1.30 cross-compiler for VMS. Now this isn't easy. There is just one #define VMS which means both "this will execute under VMS" and "this will produce code for VMS". So I changed all the #define VMS to #define VMSc wherever it seemed to mean the former. This worked after I'd grabbed a few .H files from the old VMS release, and used -I. This produced a .s file which the VMS gas almost liked. It didn't like: _yydebug: .long 0 .comm _yydebug,0 It said that was "illegal attempt to redfine _yydebug". I put the .comm line before the other 2 and it was happy. This is a bug somewhere in cc1. Well that now all compiled and linked without error. But the resulting compiler bombs out compiling a simple program. The next steps look less trivial than the ones I have taken, and perhaps I should do some real work :-(. Has anyone else had a go at this? I could try using my 1.30 cross compiler for everything in case 1.22 is producing bad code. Or make a debug version of the compiler and try to understand what is going on. Helppppppppppppp! Bob Smart, CSIRO Division of Information Technology, Australiaor P.S. The GCC 1.30 distribution is also missing lots of the bits necessary to make a complete VMS distribution: VMS style .H files; the source of GCC.EXE; the source of extra library routines in GCCLIB.OLB. I am assuming these are unchanged from 1.22.