Обсуждение: 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/