toma@swsrv1.cirr.com (Tom Armistead) (04/21/91)
I have gcc 1.39 on System Vr4. It compiled with just a little trouble,
but when I compile things with, if they include anything from /usr/include,
gcc croaks on some ?ANSI? stuff in the .h files.
This is what causes the problem:
#ifdef __STDC__
#if #machine(pdp11)
# define ULIMIT 512
#endif
#endif
Can anybody tell me what the '#machine' is supposed to do? gcc just doesn't
understand it? Is it a gcc problem? Or is it a new ANSI thing?
Thanks for ANY help...
Tom
--
Tom Armistead - Software Services - 2918 Dukeswood Dr. - Garland, Tx 75040
===========================================================================
toma@swsrv1.cirr.com {egsner,letni,ozdaltx,void}!swsrv1!tomatony@mcrsys.UUCP (Tony Becker) (04/23/91)
From article <1991Apr21.014544.16923@swsrv1.cirr.com>, by toma@swsrv1.cirr.com (Tom Armistead): > This is what causes the problem: > > #if #machine(pdp11) tom: run the fixincludes-V4 shell script that comes with gcc-1.39. it will convert all of your /usr/include/*.h files from #machine(...) to #if defined(...), and stuff them in /usr/local/lib/gcc-include for gcc to use. It's a gotcha. tony. -- tony ,....
james@bigtex.cactus.org (James Van Artsdalen) (04/29/91)
In <1991Apr21.014544.16923@swsrv1.cirr.com>, toma@swsrv1.cirr.com (Tom Armistead) wrote: > I have gcc 1.39 on System Vr4. It compiled with just a little > trouble, but when I compile things with, if they include anything from > /usr/include, gcc croaks on some ?ANSI? stuff in the .h files. Use the fixincludes-V4 shell script included with gcc. It will correct most of these include file bugs. > #if #machine(pdp11) > Can anybody tell me what the '#machine' is supposed to do? Nothing. It's worthless. Even fixincludes-V4 won't cure every instance of this: you may also want to edit /usr/ucbinclude and delete the crap from there too. > gcc just doesn't understand it? Is it a gcc problem? Or is it a new > ANSI thing? gcc works fine here. AT&T screwed up. Someone must have been on a stupid drug - there was no call for introducing that sort of incompatibility. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
shap@shasta.Stanford.EDU (shap) (04/29/91)
In article <59420@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >In <1991Apr21.014544.16923@swsrv1.cirr.com>, toma@swsrv1.cirr.com > (Tom Armistead) wrote: >> #if #machine(pdp11) > >> Can anybody tell me what the '#machine' is supposed to do? > >gcc works fine here. AT&T screwed up. Someone must have been on a >stupid drug - there was no call for introducing that sort of >incompatibility. The #machine is related to the AT&T #assert extension, and indeed someone was taking their stupid pills, because the last time I looked both the #machine style hack and the #assert stuff were not ANSI compliant. What's REALLY dumb is that they could have done it just as easily by using the preprocessor's leading-underscore namespace to implement the same thing with complete compatibility. The way it works is that you can say #assert machine pdp11 And later you can say #if machine(pdp11) The word 'machine' is just a sample usage - both the predicate and the condition appear to be user supplied identifiers of any kind. Since this stuff is not ANSI compliant, can we please start a flame war to remove these things from the source code? It essentially guarantees that all AT&T code is nonportable, and that a third-party C compiler has to implement this non-ANSI extension to run successfully on an AT&T V4 system (only if it wants to make use of header files, of course, but still...). Jonathan Shapiro
bill@alembic.acs.com (Bill Hatch) (05/01/91)
In article <59420@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >In <1991Apr21.014544.16923@swsrv1.cirr.com>, toma@swsrv1.cirr.com > (Tom Armistead) wrote: > >> I have gcc 1.39 on System Vr4. It compiled with just a little >> trouble, but when I compile things with, if they include anything from >> /usr/include, gcc croaks on some ?ANSI? stuff in the .h files. If you use the -traditional option (__STDC__ not defined or 0) gcc should work fine on V4. This is a quick fix - then fix the include files as Jim A. recommends. -- Bill Hatch (301)470-3839(w) (301)441-1675(h) Coleman Research, 14504 Greenview Drive, Laurel MD 20708 All opinions expressed are my own - dont blame my employer or alembic systems