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
#endifin 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
#endifin 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/