Thread: 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
"Arno A. Karner" <karner@tnss.com> 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
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....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 |
"Billy G. Allie" <bga@mug.org> 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
* Tom Lane <tgl@sss.pgh.pa.us> [001204 09:27]: > "Billy G. Allie" <bga@mug.org> 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: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Tom Lane wrote: > "Billy G. Allie" <bga@mug.org> 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'.
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 peter_e@gmx.net http://yi.org/peter-e/