Re: [HACKERS] compiling pg 7.0.3 on sco 5.0.5
* Tom Lane [EMAIL PROTECTED] [001204 09:27]: "Billy G. Allie" [EMAIL PROTECTED] writes: ... The DISABLE_COMPLEX_MACRO definition was originally put in to work around a macro size limitation of the UnixWare 2.1 C compiler (and later the SCO UDK (Universal Development Kit)). If the gnu C compiler is being used it should not be defined. Hm. Is anyone likely to still be using a version of that compiler that still has such limitations? I ask because we recently pulled "#define DISABLE_COMPLEX_MACRO" from port/sco.h, on the grounds that various people were seeing more harm than good from it. But I'm suddenly wondering whether those people might've been using gcc. I wonder if #ifndef __GNUC__ #define DISABLE_COMPLEX_MACRO #endif in port/sco.h would be the smart way to go. Based on my running both CURRENT UDK and GCC on my UnixWare 7 boxes with CURRENT sources, I think we may need to see if anyone complains. LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] compiling pg 7.0.3 on sco 5.0.5
Tom Lane wrote: "Billy G. Allie" [EMAIL PROTECTED] writes: ... The DISABLE_COMPLEX_MACRO definition was originally put in to work around a macro size limitation of the UnixWare 2.1 C compiler (and later the SCO UDK (Universal Development Kit)). If the gnu C compiler is being used it should not be defined. Hm. Is anyone likely to still be using a version of that compiler that still has such limitations? I ask because we recently pulled "#define DISABLE_COMPLEX_MACRO" from port/sco.h, on the grounds that various people were seeing more harm than good from it. But I'm suddenly wondering whether those people might've been using gcc. I wonder if #ifndef __GNUC__ #define DISABLE_COMPLEX_MACRO #endif in port/sco.h would be the smart way to go. regards, tom lane Well I recompilied with the stock cc shipped in the SCO development package for OpenServer 5. It was released in 97'.
Re: [HACKERS] compiling pg 7.0.3 on sco 5.0.5
Tom Lane writes: I ask because we recently pulled "#define DISABLE_COMPLEX_MACRO" from port/sco.h, on the grounds that various people were seeing more harm than good from it. But I'm suddenly wondering whether those people might've been using gcc. We can be fairly certain that they weren't, unless GCC started accepting SCO's compiler flags (or someone altered the compiler flags and filed a *very* incomplete bug report). -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] compiling pg 7.0.3 on sco 5.0.5
Tom Lane wrote: This is a header bug (there's a backend header file that some bright soul put a static function declaration into :-( ... and the function Actually, it's a static function, not a declaration. The DISABLE_COMPLEX_MACRO definition was originally put in to work around a macro size limitation of the UnixWare 2.1 C compiler (and later the SCO UDK (Universal Development Kit)). If the gnu C compiler is being used it should not be defined. The function used to replace the macro was placed in the header and defined as static so that the UnixWare compiler would compile the function in-line where ever it was used. can't link outside the backend ... and ecpg includes that header, even though it has no use for the particular function). I'd suggest trying to remove the #define DISABLE_COMPLEX_MACRO from port/sco.h. If it compiles and passes regress tests that way, you're better off without the #define anyhow. -- | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|- | Dearborn, MI 48126| MSN...: [EMAIL PROTECTED] |/ |LLIE | (313) 582-1540| PGP signature
[HACKERS] compiling pg 7.0.3 on sco 5.0.5
ive got the backend stuff to compile on sco with the sdk had to add -lsocket to get rid of unresolved var gethostbyaddress. made it as far as compiling epcg compiles but fails with unresolved var nocachegetattr in pgc.o is this a yacc/lex issue if so what would be min version requirements for bison/flex replacments, easiest to port to sco 5.0.5 -- My opinions are my own and not that of my employer even if I am self employed
Re: [HACKERS] compiling pg 7.0.3 on sco 5.0.5
"Arno A. Karner" [EMAIL PROTECTED] writes: epcg compiles but fails with unresolved var nocachegetattr in pgc.o This is a header bug (there's a backend header file that some bright soul put a static function declaration into :-( ... and the function can't link outside the backend ... and ecpg includes that header, even though it has no use for the particular function). I'd suggest trying to remove the #define DISABLE_COMPLEX_MACRO from port/sco.h. If it compiles and passes regress tests that way, you're better off without the #define anyhow. There was another discussion about this on pghackers just recently... see the archives. regards, tom lane
