brant@manta.pha.pa.us (Brant Cheikes) (11/30/88)
OK, folks, I've diddled unsuccessfully with GCC as much as I intend to for the near term. I tried compiling Gnu Emacs 18.52 with GCC 1.26 (Alex Crain's binaries), GCC 1.30, and GCC 1.31, always using gcc with the -O flag. In all cases the resulting executables did not work properly, usually bombing during startup, with a Bus Error or Memory Fault. My GCC 1.31 was initially compiled with GCC 1.26, and was able to successfully compile itself. I have gotten GCC to (apparently) successfully compile some other programs, including bison and gnuchess. Yet it's so inconsistent that I don't trust it. Unless someone can show me some mistake I made, I would recommend that those without the time or ability to become intimately familiar with GCC's innards (and thus help get it working) just leave it alone. -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science brant@manta.pha.pa.us, brant@linc.cis.upenn.edu, bpa!manta!brant
thad@cup.portal.com (Thad P Floryan) (12/02/88)
Re: Brant's problems compiling using gcc (esp. 1.31) ... Brant mentioned he uses the '-O' (optimize) flag for all his gcc compiles. In one of the GNU-related newsgroups appeared a comment recently that the optimizer in gcc is "broken" (esp. in 1.31). And all the docs accompanying gcc clearly state that gcc is in a "beta" state until such time as gcc successfully compiles (and permits to run! :-) a complete "UNIX"(tm) system from the UNIX sources. Since there's apparently a known problem with gcc's optimizer, suggest you retry your experiments without the -O flag (use perhaps -g instead, since most the makefiles accompanying GNU distributions make snide references to symbols and such :-) Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
thad@cup.portal.com (Thad P Floryan) (12/03/88)
Though most the GNU software compiles (and executes!) fine on the UNIXpc,
attempts to build GNU gcc (version 1.31) run up against what appears to be
an insurmountable obstacle: lack of table space in the UNIXpc cc compiler.
Specifically: following ALL the GNU instructions, running the config.gcc
script and specifying ``3b1'', etc etc etc, THEN invoking "$ make", a
humongous number of "too much defining" error messages result (from either
building the gnulib or gcc).
I've checked all the supplied docs for cc and cpp (for the UNIXpc) and there
is no mention of any switch or option that may rectify this problem.
The AT&T docs add insult to injury by suggesting: "The diagnostics produced
by C itself are intended to be self-explanatory." (The preceeding quote from
both the User's Manual and the Programmer's Guide. Sheesh.)
Further perusal of the docs turns up NO descriptions of error messages.
Has anyone encountered this problem ("too much defining") and solved it?
If it *IS* a situation of too many "#define ...", any suggestions for a
possible workaround?
How have those who've build gcc before (on the UNIXpc) side-stepped this
problem?
The GNU docs clearly state to *NOT* use gcc itself to build the gnulib and the
first stage of compiling gcc, thus precluding use of, say, gcc-1.26 or the
recently posted gcc-1.30.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]alex@umbc3.UMD.EDU (Alex S. Crain) (12/05/88)
In article <12015@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >Re: Brant's problems compiling using gcc (esp. 1.31) ... >In one of the GNU-related newsgroups appeared a comment recently that the >optimizer in gcc is "broken" (esp. in 1.31). I think that this discussion mostly related to gcc being umable to compie TeX with -O. This is not a bug, and is fixed by the -fwriteable-strings option to gcc. The same was true with the problems compiling X11.2. >And all the docs accompanying gcc clearly state that gcc is in a "beta" >state until such time as gcc successfully compiles (and permits to run! :-) >a complete "UNIX"(tm) system from the UNIX sources. I would hardly consider UN*X a valid test of anything except perhaps the convoluted C code contest :-). UN*X (at least the Bizerkely code) is extreamly implimentation dependent and relies on specific behavior during compilation with regard to register allocation, etc. UN*X will compile under gcc after someone rewrites alot of it. -- :alex. Systems Programmer nerwin!alex@umbc3.umd.edu UMBC alex@umbc3.umd.edu
thad@cup.portal.com (Thad P Floryan) (12/05/88)
This sucker re-bounced 3 times; I stripped most the headers for brevity. If anyone identifies with the name "Brant", this is for you. Received: by cbmvax.UUCP (1.2/UUCP-Project/Commodore 12/21/87)) id AA10328; Mon, 5 Dec 88 06:51:54 est Date: Sun, 4-Dec-88 20:44:35 PST From: sun!cbmvax!drexel!MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8812050616.AB18089@drexel.UUCP> To: pyramid!portal!cup.portal.com!thad ----- Transcript of session follows ----- 550 manta.pha.pa.us!brant... User unknown To: sun!liberty!drexel!brant@manta.pha.pa.us Subject: Re: Fed up with Gnu CC Lines: 11 Date: Sat, 3-Dec-88 18:37:20 PST Hi Brant! Many thanks for the EXCELLENT suggestion to use GNU's cpp! I suppose I'm still suffering from "shell-shock" after having uucp'd all the GNU stuff from osu-cis (I don't even WANT to see my phone bill! :-) I'll try that out and report back my findings. Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
caa@midgardMidgard.MN.ORG (Charles A Anderson) (12/06/88)
In article <12042@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: |Though most the GNU software compiles (and executes!) fine on the UNIXpc, |attempts to build GNU gcc (version 1.31) run up against what appears to be |an insurmountable obstacle: lack of table space in the UNIXpc cc compiler. | |If it *IS* a situation of too many "#define ...", any suggestions for a |possible workaround? As fas as I understand, it is. |How have those who've build gcc before (on the UNIXpc) side-stepped this |problem? I've read it here on the net from people that have compiled gcc that you have to use the gnu cpp, a uuencode executable was posted a long time ago, and it came through again when gcc 1.26 executables were posted. |The GNU docs clearly state to *NOT* use gcc itself to build the gnulib and the |first stage of compiling gcc, thus precluding use of, say, gcc-1.26 or the |recently posted gcc-1.30. Don't use gcc but use the gnu-cpp. |Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] -- Charles Anderson | People of the Earth can you hear me? caa@midgard.mn.org | Came a voice from the sky on that magical night ...!amdahl!bungia!midgard!caa | And in the colours of a thousand sunsets | They traveled to the world on a silvery light | -Billy Thorpe, Children Of The Sun