bgh@ice9.uucp (barry hannigan) (03/01/90)
the following lines are excerpted from /usr/include/sys/types.h in ISC 2.0.2
typedef struct { int r[1]; } * physadr;
typedef char * caddr_t; /* ?<core address> type */
typedef char * faddr_t; /* same as caddr_t for 8086/386 */
they cause syntax errors when used.
the program being compiled is Xloadimage, patchlevel 3.
any ideas?
barry.
--
return path = uunet!alberta!ncc!ice9!bghcpcahil@virtech.uucp (Conor P. Cahill) (03/05/90)
In article <1990Mar1.022620.23226@ice9.uucp> bgh@ice9.uucp (barry hannigan) writes: >the following lines are excerpted from /usr/include/sys/types.h in ISC 2.0.2 [stuff from types.h deleted] >they cause syntax errors when used. No. They don't. The fact that they are in sys/types.h indicates that the entire system, including the kernel was built with them, so I doubt they cause a problem. >the program being compiled is Xloadimage, patchlevel 3. > >any ideas? I would guess that there is a typedef or variable in the Xloadimage source code. Since you didn't show the compiler output, one can only guess what the problem is. Whenever you post a question about a specific compiler/system/command error, be sure to include the error message that you are talking about. It is especially hard to debug a problem without seeing the output. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
bright@sctc.com (Dave Bright) (03/05/90)
bgh@ice9.uucp (barry hannigan) writes: >the following lines are excerpted from /usr/include/sys/types.h in ISC 2.0.2 >typedef struct { int r[1]; } * physadr; >typedef char * caddr_t; /* ?<core address> type */ >typedef char * faddr_t; /* same as caddr_t for 8086/386 */ >they cause syntax errors when used. >the program being compiled is Xloadimage, patchlevel 3. >any ideas? Since I've run into this while compiling several X clients under ESIX, I thought it worthwhile to post a response. The problem is that one of the X11 include files (I don't recall which) includes sys/types.h. When the program includes sys/types.h explicitly, the typedefs die due to redefinition. My solution so far has been to just comment out the include in the program, but I've been thinking of modifying the include file to allow multiple inclusions; this might save time in the long run. -- David A. Bright Secure Computing Technology Corporation bright@SCTC.COM (work) 1210 West County Road E, Suite 100 dab@Bright.MN.ORG (home) Arden Hills, MN 55112
jackv@turnkey.TCC.COM (Jack F. Vogel) (03/06/90)
In article <1990Mar1.022620.23226@ice9.uucp> bgh@ice9.uucp (barry hannigan) writes: >the following lines are excerpted from /usr/include/sys/types.h in ISC 2.0.2 >typedef struct { int r[1]; } * physadr; >typedef char * caddr_t; /* ?<core address> type */ >typedef char * faddr_t; /* same as caddr_t for 8086/386 */ >they cause syntax errors when used. Barry, there is nothing wrong with types.h, what is actually happening is that it is being included twice and the second pass through this stuff by the preprocessor causes the syntax error. You need to search through the include files, find the second inclusion and remove it. I have found the X source to be notorious for this problem. Oh, BTW, the GNU gcc compiler gives error messages that make it a lot more obvious what the problem is (it actually tells you there was a previous declaration). Disclaimer: I speak for myself, not for LCC. -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
pax@megasys.COM (Garry M. Paxinos) (03/08/90)
In article <1990Mar1.022620.23226@ice9.uucp> bgh@ice9.uucp (barry hannigan) writes:
the following lines are excerpted from /usr/include/sys/types.h in ISC 2.0.2
typedef struct { int r[1]; } * physadr;
typedef char * caddr_t; /* ?<core address> type */
typedef char * faddr_t; /* same as caddr_t for 8086/386 */
they cause syntax errors when used.
the program being compiled is Xloadimage, patchlevel 3.
any ideas?
Yes, the problem is sys/types.h is being include more than once (generaly
inside the X11/*.h files..) What I've done is to #ifdef the sys/*.h files
so they only get parsed once.
ie :
#ifndef _h_sys_types
#define _h_sys_types
<... standard text of sys/types.h ...>
#endif /* _h_sys_types */
--
Internet : work - pax@megasys.com home - pax@ankh.ftl.fl.us
USNail : Megasystems, Inc. 2055 South Congress Ave, Delray Beach, FL 33445
UUCP : {gatech!uflorida!novavax!ankh, mthvax, attmail}!megasys!pax
Voice : 407-243-2405 Data: 407-243-2407 Fax: 407-243-2408 Telex: 156281499daveb@i88.isc.com (David G. Burton) (03/08/90)
In article <1990Mar1.022620.23226@ice9.uucp> bgh@ice9.uucp (barry hannigan) writes: | [<sys/types.h> lines that cause syntax errors] In article <6730@turnkey.TCC.COM> jackv@turnkey.TCC.COM replies: |Barry, there is nothing wrong with types.h, what is actually happening is |that it is being included twice and the second pass through this stuff by |the preprocessor causes the syntax error. You need to search through the |include files, find the second inclusion and remove it. I have found the |X source to be notorious for this problem. I have ``frequently'' run into this problem with <sys/types.h> when porting software to my machine. Rather than modifying the various sources to remove redundant #include's, I simply modify <sys/types.h> as in: $ cat /usr/include/sys/types.h #ifndef SYS_TYPES_H #define SYS_TYPES_H ... [ all of header file ] ... #endif /* SYS_TYPES_H */ $ Once this modification is made, no further problems due to multiple inclusion of <sys/types.h> will occur. Disclaimer: I don't speak for ISC; they don't speak for me. -- Dave Burton uunet!ism780c!laidbak!daveb