ftp.nice.ch/peanuts/GeneralData/Usenet/news/1989/CSN-89.tar.gz#/comp-sys-next/1989/May-Jun/How-to-get-GCC-source?

This is How-to-get-GCC-source? in view mode; [Up]


Date: Sun 23-May-1989 02:54:29 From: Unknown Subject: Re: How to get GCC source? (And G++) 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 >From: henry@dehn. (Henry Cejtin)

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.