ilan343@violet.berkeley.edu (Geraldo Veiga) (12/18/90)
I am trying to compile gcc 1.37.1 under ISC 2.2 using cc. Can anyone that has already done this give me a hint of where I went wrong? I am using Bison 1.11. Thanks in advance. Here is a rundown of what happened: 1. Change Makefile: CLIB= -lPW 2. Change stddef.h: Replace _T_SIZE for _SIZE_T which doesn't match the constant defined in` ISC's <sys/types.h> (Is this a bug? Which one is standard?) 3. Run config.gcc i386-sysv 4. Run make. Everything went fine, except for the following message: make hard-params cp ./hard-params.c . > /dev/null 2>&1 *** Error code 2 (ignored) cc -DNO_SC -c hard-params.c 5. Where is `README-ENCAP'? I didn't do anything about COFF. Do I have to? 6. Run make stage1. 7. Run make CC=stage1/gcc CFLAGS="-g -O -Bstage1/ -msoft-float" Terminated in error. /usr/include/sys/stat.h:97: parse error before `mode_t' Here's the output for the last make: touch stamp-gnulib2 stage1/gcc -g -O -Bstage1/ -I. -I. -I./config \ -DSTANDARD_STARTFILE_PREFIX=\"/usr/local/lib/\" \ -DSTANDARD_EXEC_PREFIX=\"/usr/local/lib/gcc-\" -c \ `echo ./gcc.c | sed 's,^\./,,'` stage1/gcc -c -g -O -Bstage1/ -I. -I. -I./config version.c stage1/gcc -c -g -O -Bstage1/ -I. -I. -I./config obstack.c stage1/gcc -g -O -Bstage1/ -o gccnew gcc.o version.o obstack.o -lPW mv gccnew gcc stage1/gcc -g -O -Bstage1/ -I. -I. -I./config -c ./c-parse.tab.c stage1/gcc -c -g -O -Bstage1/ -I. -I. -I./config c-decl.c stage1/gcc -c -g -O -Bstage1/ -I. -I. -I./config c-typeck.c stage1/gcc -c -g -O -Bstage1/ -I. -I. -I./config c-convert.c stage1/gcc -c -g -O -Bstage1/ -I. -I. -I./config toplev.c In file included from toplev.c:32: /usr/include/sys/stat.h:95: parse error before `mode_t' /usr/include/sys/stat.h:97: parse error before `mode_t' /usr/include/sys/stat.h:98: parse error before `mode_t' *** Error code 1 Stop.
jim@segue.segue.com (Jim Balter) (12/19/90)
In article <1990Dec17.190525.16868@agate.berkeley.edu> ilan343@violet.berkeley.edu (Geraldo Veiga) writes: >/usr/include/sys/stat.h:97: parse error before `mode_t' Find the line #if defined(_POSIX_SOURCE) || defined(POSIX_JC) in /usr/include/sys/types.h and change it to #if 1 This will fix the mode_t problem. There seems to be wide misunderstanding of the meaning of _POSIX_SOURCE. The user can define _POSIX_SOURCE to guarantee a clean POSIX namespace. But nothing should ever be *excluded* if _POSIX_SOURCE *isn't* defined. There are also problems with __STDC__. An ANSI C compiler is supposed to define this; you can make the use of prototypes and ANSI C preprocessor semantics conditional upon __STDC__. BUt __STDC__, unlike _POSIX_SOURCE, is not defined by the user and should not be used to *exclude* non-ANSI features. Some other symbol should be used to get a clean ANSI namespace. POSIX 1003.1 recommends __STDH__; GCC uses __STRICT_ANSI__. While the proper usage of __STDC__ with regard to non-strictly conforming implementations isn't discussed in the C Standard, it was discussed in committee, and was mentioned in one of the responses to public comments. SysV.4 has a rather bizarre "solution": defining __STDC__ as 0 will allow non-ANSI features in standard headers. I don't understand the thinking that can lead to the default on a UNIX system being that fileno isn't defined. It doesn't reflect a high "quality of implementation".
jim@segue.segue.com (Jim Balter) (12/20/90)
In article <1990Dec18.210054.23004@agate.berkeley.edu> ilan343@violet.berkeley.edu (Geraldo Veiga) writes: >I just finished recompiling gcc (stage1) using -traditional switch and >went through with no apparent glitches. Should I still "fix" types.h? In the ISC 2.2 headers, the POSIX types usually occur within ifdef _POSIX_SOURCE. In stat.h they botched it (aside from their botched use of _POSIX_SOURCE) and use these types in function prototypes. But since the prototypes are only compiled under ifdef __STDC__, stat.h is ok if you use cc or gcc -traditional. But *any* program that uses <sys/stat.h> will have to be compiled -traditional unless you fix stat.h or types.h, or define _POSIX_SOURCE, which will give you a whole host of other problems. >Is the "_POSIX_SOURCE" definition generic SysV 3.2 or Interactive's >enhancement? It wasn't in ISC releases prior to 2.2, so it may have been added by ISC. The important point is that it is in some systems but not others. >I am sort of reluctant of messing around with standard header files, I >want to keep my code portable. Well, you can put the changed headers in gcc-include so you don't have to touch the distributed versions. For maximal portability among UNIX systems, stick with good ole K&R -traditional, and hope that no one hands you code that uses ANSI C features.