jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) (09/07/90)
With all this hub-bub about FSF and GnuC, does anyone really think GnuC
is all that good?
I have the Unisoft Optimizing C Compiler for A/UX (GreenHills), A/UX cc
and GnuC 1.37.91. Without a doubt, the Unisoft compiler makes tight, fast
code. cc isn't very fast or tight, but very stable. And it supports shared
libraries (Unisoft doesn't... see below). But I've had NOTHING but bad luck
using GnuC (gcc)!! Weird behavior, core dumps, crashes, bombs, etc...
It seems like it's a piece of crap... well, at least that's been my experience
with it. For now, I'll stick with Unisoft (when I need speed) and cc with
-lc_s (when I want to save a little space... that's all it really saves,
about 7% most of the time).
Anyway, the version of Unisoft that I have is 1.8.2H, and kinda old. It
doesn't support either shared libraries OR shared executables. Does anyone
know how I can contact Unisoft Corporation and see if there is an upgrade
available for the latest version (hopefully using 2.0 enhancements). Are
they on Applelink? If you have ANY info, please send me some E-mail. Thanks!
PS: I've checked my port of Sendmail 5.64 with shared libraries (using cc)
and it works quite nicely. As before, ports of Sendmail 5.64, in.ftpd and
in.fingerd ("latest versions") are available via anon-ftp on jagmac2...
--
=======================================================================
#include <std/disclaimer.h>
=:^)
Jim Jagielski NASA/GSFC, Code 711.1
jim@jagmac2.gsfc.nasa.gov Greenbelt, MD 20771
"Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach
the very, very top, and then it tends to slope away rather sharply."rmtodd@servalan.uucp (Richard Todd) (09/10/90)
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: >With all this hub-bub about FSF and GnuC, does anyone really think GnuC >is all that good? Yes. >I have the Unisoft Optimizing C Compiler for A/UX (GreenHills), A/UX cc >and GnuC 1.37.91. Without a doubt, the Unisoft compiler makes tight, fast >code. cc isn't very fast or tight, but very stable. And it supports shared >libraries (Unisoft doesn't... see below). But I've had NOTHING but bad luck >using GnuC (gcc)!! Weird behavior, core dumps, crashes, bombs, etc... A/UX cc stable??? Well, now that they've *finally* made it so you can up the table sizes of the compiler from the command line it's at least possible to compile large files; as it was, you had to use either the GNU C or the DECUS C preprocessor to compile X11R4, since the include files for X11 had more defines than A/UX cpp could withstand. I still don't trust it for anything really large and complicated, though. I dunno about weird behavior and core dumps, but I've got all of X11R4, plus Emacs, GCC, and several other programs all compiled with gcc, and haven't had any problems. I trust you *do* know about compiling with -fwritable-strings? GCC by default puts string constants in text space where they can't be modified, as ANSI C allows. Alas, broken implementations of sscanf, like Apple's, try to write to the string they're scanning, which means that if you're passing a constant string to sscanf, it dies with SIGSEGV unless you compiled with -fwritable-strings. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp
scott@unisoft.UUCP (Scott Gustafson) (09/11/90)
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: >Anyway, the version of Unisoft that I have is 1.8.2H, and kinda old. It >doesn't support either shared libraries OR shared executables. Does anyone >know how I can contact Unisoft Corporation and see if there is an upgrade >available for the latest version (hopefully using 2.0 enhancements). Are >they on Applelink? If you have ANY info, please send me some E-mail. Thanks! Well, if you need to contact someone who works for UniSoft, call me. As far as the upgrade goes, there hasn't been enough interest in the original product to warrant a new release. I still use the old version with AU/X 1.1.1 along with the other compilers for Fortran and Pascal. If you would like to see a new release (which I have been puching for), send me some mail and I will forward it to the Prez. for approval. I would like to see the new release out soon with complete 2.0 compatibility. Next, as for the Applelink, we used to have an AppleLink account when we were developing the Compilers and other misc. junk, but it has been discontinued. See my .sig file for the machines we talk to and my address and phone number. scott ----- Scott Gustafson UniSoft Corp., 10700 N. DeAnza Blvd., Cupertino, CA 95014 (408) 366-4901 {uunet,hoptoad,fai,bdt,sun,lll-lcc,mtxinu,basis,ucbvax,apple}!unisoft!scott
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) (09/11/90)
In article <1990Sep10.002711.22219@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: > >>I have the Unisoft Optimizing C Compiler for A/UX (GreenHills), A/UX cc >>and GnuC 1.37.91. Without a doubt, the Unisoft compiler makes tight, fast >>code. cc isn't very fast or tight, but very stable. And it supports shared >>libraries (Unisoft doesn't... see below). But I've had NOTHING but bad luck >>using GnuC (gcc)!! Weird behavior, core dumps, crashes, bombs, etc... > >A/UX cc stable??? By stable, I mean that it produces solid code. Maybe stable was the wrong term, but I stand behind my opinion. > I trust you *do* know about compiling with >-fwritable-strings? GCC by default puts string constants in text space where >they can't be modified, as ANSI C allows. Alas, broken implementations of >sscanf, like Apple's, try to write to the string they're scanning, which means >that if you're passing a constant string to sscanf, it dies with SIGSEGV unless >you compiled with -fwritable-strings. Maybe that was it... I was compiling with -traditional. This happened with my port of ftpd, sendmail and fingerd, which all use sscanf (amongst others) so that may be the problems. Seems to me, the default should be -fwri* since, as I understand it, this is basically an ANSI "feature", and should be added when one selects -ansi... Thanks for the help, but maybe my attitude towards gcc may be a little tainted by FSF and their "holier than thou" attitude. -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagmac2.gsfc.nasa.gov Greenbelt, MD 20771 "Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach the very, very top, and then it tends to slope away rather sharply."
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) (09/11/90)
In article <1990Sep10.002711.22219@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: > >>I have the Unisoft Optimizing C Compiler for A/UX (GreenHills), A/UX cc >>and GnuC 1.37.91. Without a doubt, the Unisoft compiler makes tight, fast >>code. cc isn't very fast or tight, but very stable. And it supports shared >>libraries (Unisoft doesn't... see below). But I've had NOTHING but bad luck >>using GnuC (gcc)!! Weird behavior, core dumps, crashes, bombs, etc... > > *** misc stuff about things Richard has successfully compiled *** >-- Since my posting, I have recieved a LOT of mail about problems that others have had with gcc 1.37.91 (not only A/UX version, but others). What version are you using and running... that may be the problem too. Then again, who knows? I'll try gcc a few more times, but considering that it's behavior is not the same as cc, I may still drop it. After all, how can you make sure that every little flag that you need is set, until the program craps out on you? And then, how can you tell which one... Considering that most app's are written and compiled using cc (since it's included with most platforms), cc may still be a "safe" bet... -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagmac2.gsfc.nasa.gov Greenbelt, MD 20771 "Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach the very, very top, and then it tends to slope away rather sharply."
rmtodd@servalan.uucp (Richard Todd) (09/12/90)
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: >>A/UX cc stable??? >By stable, I mean that it produces solid code. Maybe stable was the wrong >term, but I stand behind my opinion. Okay, I'll agree with you here. When A/UX cc does compile a program, it does seem to compile it correctly. [talking about the infamous -fwritable-strings] >Maybe that was it... I was compiling with -traditional. This happened with >my port of ftpd, sendmail and fingerd, which all use sscanf (amongst others) >so that may be the problems. Seems to me, the default should be -fwri* since, >as I understand it, this is basically an ANSI "feature", and should be added >when one selects -ansi... Perhaps it should. In fact, it shouldn't be difficult to hack the gcc driver to do just that. Of course, it'd be better if Apple also fixed the bug in sscanf/ungetc that does this; sscanf really has no business trying to write to its input. I certainly never had suspected that sscanf did such a thing until the reports came out on comp.windows.x (among other places) about the bug. >Thanks for the help, but maybe my attitude towards gcc may be a little tainted >by FSF and their "holier than thou" attitude. And perhaps my attitude towards A/UX cc is tainted by AT&T and their attitude of "God forbid we should go to the trouble of mallocing what we can statically allocate. You want to compile something with more than 32K of #defines? Too bad. See Figure 1." -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp
rmtodd@servalan.uucp (Richard Todd) (09/12/90)
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: >Since my posting, I have recieved a LOT of mail about problems that others have >had with gcc 1.37.91 (not only A/UX version, but others). What version are you >using and running... that may be the problem too. Gcc 1.37.91 binaries, ftp'ed from wuarchive.wustl.edu in late August. If you got them from there earlier than that, you might want to try again; it looks like sometime in August John Coolidge placed an updated version on there, with a new version of gas that does fix a rather nasty bug. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp