jak9213@helios.TAMU.EDU (John Kane) (12/02/89)
The subject about says it. I have A/UX 1.1, the gcc files from apple.com Following the instructions in the README, I get to the point where a do a new "make". everything works for a while, but I then get the message "too many defines". What am I doing wrong? Thanks. John Arthur Kane, Systems Analyst, Microcomputer Support and Training Texas A&M University, College Station, TX 77843 (409) 845-9999 jak9213@helios.tamu.edu profs: x043jk@tamvm1.tamu.edu
rmtodd@servalan.uucp (Richard Todd) (12/04/89)
In article <3961@helios.TAMU.EDU> jak9213@helios.TAMU.EDU (John Kane) writes: >The subject about says it. > >I have A/UX 1.1, the gcc files from apple.com > >Following the instructions in the README, I get to the point where a do >a new "make". everything works for a while, but I then get the message >"too many defines". The problem is that the source for gcc is too complex for Apple's C compiler to handle. Believe it or not, the stock AT&T-derived CPP allocates space for handling defines from a *fixed size buffer* (32K, I believe), and if your source code has more #defines than that, tough. Rumour has it that in SVR4 AT&T has finally learned about malloc(3) and fixed this piece of braindamage, but that's not much help to us now. So how do you compile gcc? Well, you need a compiler and C preprocessor that allocate space for #defines and other stuff dynamically instead of using fixed-size buffers. I.e., you need GCC binaries. Fortunately, there's a set of gcc binaries already made up and sitting there on apple.com; I forget the exact file name but it's in the same directory with gcc's source, so it should be easy to find. Then simply hack the makefiles etc. to use gcc instead of cc and everything should be just fine. Of course, there's no real reason to compile gcc when you've got the binaries available, unless you want to hack on it; if all you're interested in is being able to use the superior optimizations, ANSIness, etc. of gcc, you can just install the binaries and go home for the day. *FLAME ON* I'm still shocked that the standard compiler is braindead in this fashion. Compilers should not run out of table space for *anything* except when you've actually used up all the available memory space in the system. Great Ghu, Ron Cain's Small-C managed to get this right back in 1980; why couldn't the mighty AT&T Unix Systems Group? Malloc just ain't that hard to use, guys! *FLAME OFF* (Final note for the curious: It ain't just the C Preprocessor that runs into buffer-size limits with the GCC source; even if you get around that, various expressions in the GCC source cause the C compiler proper to fill up *its* fixed-size tables. Sigh.) -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp Motorola Skates On Intel's Head!
jak9213@helios.TAMU.EDU (John Kane) (12/05/89)
In article <1989Dec4.062116.3446@servalan.uucp>, rmtodd@servalan.uucp (Richard Todd) writes: > In article <3961@helios.TAMU.EDU> jak9213@helios.TAMU.EDU (John Kane) writes: > >The subject about says it. > > > >I have A/UX 1.1, the gcc files from apple.com > > > >Following the instructions in the README, I get to the point where a do > >a new "make". everything works for a while, but I then get the message > >"too many defines". > The problem is that the source for gcc is too complex for Apple's C compiler > to handle. Believe it or not, the stock AT&T-derived CPP allocates space > for handling defines from a *fixed size buffer* (32K, I believe), and if > your source code has more #defines than that, tough. Rumour has it that > in SVR4 AT&T has finally learned about malloc(3) and fixed this piece of > braindamage, but that's not much help to us now. > So how do you compile gcc? Well, you need a compiler and C preprocessor > that allocate space for #defines and other stuff dynamically instead of > using fixed-size buffers. I.e., you need GCC binaries. Fortunately, > there's a set of gcc binaries already made up and sitting there on > apple.com; I forget the exact file name but it's in the same directory with > gcc's source, so it should be easy to find. Then simply hack the makefiles > etc. to use gcc instead of cc and everything should be just fine. Of > course, there's no real reason to compile gcc when you've got the binaries > available, unless you want to hack on it; if all you're interested in is > being able to use the superior optimizations, ANSIness, etc. of gcc, you > can just install the binaries and go home for the day. > [stuff deleted] > Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us > rmtodd@servalan.uucp > Motorola Skates On Intel's Head! My mistake, I should have mentioned that I was running the gcc binaries from apple.com. I still got the error, but at this time I cannot absolutely state that it was compiled with gcc, but I feel very strongly that it was. I have been beating against this for about a week. If I can't get it to compile, how can I ever install future patches? I have been having problems installing other software. I guess that I am used to the Sun 3/280 environment that I have done most of my work on. Getting used to SVR2 is a pain, but I have no choice. BTW - has anyone ever installed Perl 3.0 successfully? I was/am having troubles doing so, and this lead me to trying to get gcc up and running, which lead to this problem, ad nauseum. Thanks. John Arthur Kane, Systems Analyst, Microcomputer Support and Training Texas A&M University, College Station, TX 77843 (409) 845-9999 jak9213@helios.tamu.edu profs: x043jk@tamvm1.tamu.edu
kowalski@svax.cs.cornell.edu (Jeffrey Kowalski) (12/05/89)
Someone writes: > can't get GCC to compile Well, sure you can't. As discussed the CC from AT&T is a piece of junk - fixed tables et al. Well, even if you've got the gcc, you can't compile it because the assembly portion of the compile process is messed up. I keep getting horrible errors. Could I be correct in guessing that our friend "as" has the same limit as "cc?" Jeff (sigs are for the insecure)
rmtodd@servalan.uucp (Richard Todd) (12/05/89)
In article <34840@cornell.UUCP> kowalski@svax.cs.cornell.edu (Jeffrey Kowalski) writes: >Well, even if you've got the gcc, you can't compile it because the >assembly portion of the compile process is messed up. I keep getting >horrible errors. Could I be correct in guessing that our friend >"as" has the same limit as "cc?" Oops, forgot about that. Yes, "as" has fixed-length tables that will overflow -- if you turn on the -g flag on your compiles to include symbolic debugging information. Leave off -g in the CFLAGS when trying to build gcc and everything works ok. I've done it, it works. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp Motorola Skates On Intel's Head!
steveg@umd5.umd.edu (Steve Green) (12/05/89)
One suggestion. Make a link from /usr/lib/big/as to /usr/local/lib/gcc-as. Also, this will often stop the assembly errors. As long as this subject has come up again... has ANYONE been able to build a stage 3 gcc on AUX????
aem@mthvax.cs.miami.edu (a.e.mossberg) (12/05/89)
gcc 1.35 with patches 1-3 applied is now available for anonymous ftp from mthvax.cs.miami.edu (129.171.32.5) This was compilied from the sources on apple.com, so if you want to go the long way, by all means, try. I think, though I can't remember, that it was something real simple to get it to compile (but frustrating trying to find). Save time, save money, come to crazy andrew's ftp house for the latest in discount sources! aem -- a.e.mossberg / aem@mthvax.cs.miami.edu / aem@umiami.BITNET / Pahayokee Bioregion Love is a cursed nuisance when coupled with lust also. - James Joyce
russotto@eng.umd.edu (Matthew T. Russotto) (12/06/89)
In article <1989Dec4.062116.3446@servalan.uucp> rmtodd@servalan.UUCP (Richard Todd) writes: > The problem is that the source for gcc is too complex for Apple's C compiler >to handle. Believe it or not, the stock AT&T-derived CPP allocates space >for handling defines from a *fixed size buffer* (32K, I believe), and if >your source code has more #defines than that, tough. Rumour has it that >in SVR4 AT&T has finally learned about malloc(3) and fixed this piece of >braindamage, but that's not much help to us now. How about the C compiler in /usr/lib/big? Is it able to handle gcc? Not that it really matters of course-- given gcc binaries, gcc can be used to compile itself, so this would just save a little download time. Anyone else think it's ironic that Gnu's own philosophy prevents them from stopping 'Evil Apple' from distributing their software...? 32K buffers? Someone think that they are still using the 6502? Ack. >-- >Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us > rmtodd@servalan.uucp >Motorola Skates On Intel's Head! -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?
rmtodd@servalan.uucp (Richard Todd) (12/07/89)
In article <1989Dec5.214610.25071@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >How about the C compiler in /usr/lib/big? Is it able to handle gcc? Nope. I'm not sure how big the buffers are in that version, but they *still* aren't big enough. >32K buffers? Someone think that they are still using the 6502? Ack. Actually, I assume it's leftovers from the heyday of the PDP-11. Sigh. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp Motorola Skates On Intel's Head!