phd_ivo@GSBACD.UCHICAGO.EDU (05/24/89)
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
schmidt@ics.uci.edu (Doug Schmidt) (05/24/89)
In article <8905240246.AA02559@life.ai.mit.edu> phd_ivo@GSBACD.UCHICAGO.EDU writes:
++ 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.
If you have version 0.8 of NeXT's OS then you are probably out of luck
as far as getting G++ installed. Apparently there is a bug in NeXT's
malloc that causes problems when compiling g++ with gcc. We just got
our 0.9 upgrade a couple days ago. I'll attempt to get g++ up and
running soon. If things go well I'll post a note, if not......
Doug
--
On a clear day, under blue skies, there is no need to seek.
And asking about Buddha +------------------------+
Is like proclaiming innocence, | schmidt@ics.uci.edu |
With loot in your pocket. | office: (714) 856-4043 |