michael@python.UUCP (M. Cain) (07/17/86)
I'm trying to port C++ to a Hewlett-Packard 550 running HPUX. I was able to make cfront from the ..c files in the distribution. However, cfront complains that "this c does not support varargs" when compiling some parts of the library and the C++ source for cfront. HPUX *does* support varargs -- but the 550 runs its stack "backwards" from the way its done on a VAX. Taking one of the guidelines to heart, I checked to see if the HPUX header files were compatible with the headers in the distribution. Varargs.h certainly wasn't. Since I have limited access to a VAX, I built a working cfront there, changed varargs.h to reflect the 550 way of doing things, and compiled the .c files to produce new ..c files. Took those back to the 550. No difference. Grepping the C++ source for cfront and the distributed include files, I found that none of them reference varargs.h. This seems to imply that the code hardwires assumptions about the stack, rather than using the stuff in varargs.h. Questions: Has anyone else had this problem in doing a port? Does anyone have any suggestions for fixing the problem? Thanks in advance for any advice... Mike Cain Bell Communications Research ..!python!michael
bs@alice.UucP (Bjarne Stroustrup) (07/18/86)
> From: michael@python.UUCP (M. Cain) > Organization: Bell Communications Research > > I'm trying to port C++ to a Hewlett-Packard 550 running > HPUX. I was able to make cfront from the ..c files in > the distribution. However, cfront complains that "this > c does not support varargs" when compiling some parts of > the library and the C++ source for cfront. HPUX *does* > support varargs -- but the 550 runs its stack "backwards" > from the way its done on a VAX. > ... > Grepping the C++ source for cfront and the distributed > include files, I found that none of them reference varargs.h. > This seems to imply that the code hardwires assumptions about > the stack, rather than using the stuff in varargs.h. You are right. Cfront does those assumptions hardwired. The snag is that when I wrote it I didn't have a C++ varargs and I somehow never got around to rewriting that part of cfront. Sorry. > Questions: Has anyone else had this problem in doing a port? > Does anyone have any suggestions for fixing the problem? Yes (are you there Chris?). Actually someone just solved that exact problem for a Data General machine, but I don't have the code. The assumptions are locallized to the function error() in error.c. Error() does a printf-style passing of error message format strings. Fix the way it gets at its arguments and cfront will run. The same problem occurs in the function form() in file out.c in the stream library.