gore@eecs.nwu.edu (Jacob Gore) (05/22/89)
What's the exact procedure for getting the source to GCC on NeXT
(specifically, the back end stuff)?
Jacob Gore Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gorephd_ivo@gsbacd.uchicago.edu (05/23/89)
It's available via anonymous ftp from prep.ai.mit.edu. You can also check your emacs' xinfo help for emacs distribution. It's the same as getting emacs, except you will want to get gcc-1.35* from pub/gnu. Here is what I wanted to send anyway: I spent the better part of yesterday trying to install g++. The installation documentation is not accurate, and thus a real problem. For example, among the directories g++ expects to exist, is gcc-test/ This directory exists neither on my NeXT, nor is it mentioned in the current gnu c 1.35.0 distribution. Moreover, bison.simple was hardly ever mentioned, but some of the construction files create a link to a bison.simple in the gnu cc (I think) directory; anyway, it's not there on Next but elsewhere (for non-NeXT computer: it doesn't come in the gcc tar files, either!). I have never tried to install either gnu c nor g++. One thing that astonished me is how many warning messages I got when I compiled gnu c 1.35.0 with the NeXT version of gnu c. Many of these seem benign, but as a user, one never knows. The following are some observations that may make it easier for someone who knows what he is doing (I don't) to go about installing g++ on NeXT. ---------------------------- The instructions mean that one should do a make -f Makefile maketest Specifying this line would make it much cleaner and easier to understand than 'do a make of the "maketest" target in the makefile'. Among the more disconcerting compile-time errors were a definition in cplus-lex.c extern double atof (); which in NeXT's /usr/include/stdlib.h was moved to be translated into #define atof(nptr) strtod(nptr,(char**)NULL) Obviously, this causes syntax error. A similar problem appears in expr.c (due to---I think---gnu c 1.35.1 expr.h file). What happens is that CONST0_RTX() is a macro including a conditional expression that looks like a typecast abort (rtx) abort() Well, on NeXT, abort() is void and causes the cast to be a syntax error. In final.c, the problems were getting more serious. A tmp file co(.s at 4026) signalled an unknown pseudo-op. I have no idea how to fix this. In genrecog, function fatal, I decided to check some of the warning messages about improper casts. The function uses an integer passed as the string control argument to fprintf. I realize that the purpose of this exercise is not to have to program in C (but in G++), but it seems that this sort of warning can be easily cleaned up, and would save some wondering. (I think genrecog may come from gcc, so no criticism of G++ intended). My final hour came when cc of intry-output.c died with signal 11. Some other problems were redefinitions of __builtin_alloca, mallocs and NULL. I assume NeXT has decided on its own versions of these routines. ----------------------- In any case, installation of g++ on NeXT is not a trivial streightforward exercise. It seems that there are many other people who would like to have a version of C++ running, so a porting effort by someone "in the know" would be very worthwhile enterprise. Definitely, please let me know if you (the unknown porter) have succeeded. /ivo phd_ivo@gsbacd.uchicago.edu