Here is my current list for porting status for the v6.3 release. I may
have missed at least a few reports, e.g hpux, irix??

Since the porting support has changed for v6.3, if a system is not
tested it should be assumed to be broken. Any regression test done since
Feb 1 will count as "confirmed working", as long as the test ran to
completion and for the most part behaved properly.

Any machine which does not get an installation and a regression test for
v6.3beta will move to the unsupported list. Also, let us know if you
have an interest in a port even though you cannot actually do the work
to confirm it; that may encourage someone else to volunteer.

Marc/Bruce, can you help me clarify the bsdi/freebsd/netbsd/bsdxxx
entries? I'm not sure which are unique and what the names should be...

                                                       - Tom

*  aix/4.1.4.0-4.2 - confirmed working when built on 4.1.4.0 (Darren
King)
_  aix/3.5 - not yet tested? close enough to 4.1 to count?? (Frank
Dana?)
_  bsdi
_  FreeBSD/2.2.1,2.2.5 - in progress (Tatsuo)
?  NetBSD/i386 version? - not yet tested but should work?
x  NetBSD/m68k Amiga, HP300, Mac - not yet working... (Henry Hotz)
*  NetBSD/sparc version? confirmed working (Tom Helbekkmo)
*  NetBSD/vax version? confirmed working (Tom Helbekkmo)
*  dgux/5.4R4.11 - patches submitted (Brian Gallew)
_  hpux/9.0.x
_  hpux/10.20
_  irix5
_  irix6/MIPS
_  dec/alpha - currently broken? confirmed working on v6.2.1 (Pedro)
_  linux/alpha - currently broken?
*  linux/i386 - confirmed working (Thomas)
?  linux/i386/glibc2 - minor library breakage; in progress (Oliver)
_  mklinux/ppc - in progress (Tatsuo)
_  nextstep - worked with patches on v1.0.9; not working now?
_  sco/i386
_  solaris/i386 - confirmed working (Marc)
*  solaris/sparc/2.5.1 - confirmed working (Marc)
_  solaris/sparc/2.6 - in progress (Tatsuo)
_  sunos/sparc/4.1.4 - in progress (Tatsuo)
_  svr4/MIPS - dcosx and sinix/seimens-nixdorf worked on v6.1 (Frank
Ridderbusch?)
_  ultrix4 - no recent reports? obsolete port??
x  univel - not working now; in progress? (Billy G. Allie)


Sat, 14 Feb 1998 17:03:32 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Valid ports for v6.3
On Sat, 14 Feb 1998, Thomas G. Lockhart wrote:

> Here is my current list for porting status for the v6.3 release. I may
> have missed at least a few reports, e.g hpux, irix??

	Neil, can you organize with Thomas about having a sub page from
the main WWW page that lists these?  Something visible?  Including the
disclaimer below about testing?

> Since the porting support has changed for v6.3, if a system is not
> tested it should be assumed to be broken. Any regression test done since
> Feb 1 will count as "confirmed working", as long as the test ran to
> completion and for the most part behaved properly.
> 
> Any machine which does not get an installation and a regression test for
> v6.3beta will move to the unsupported list. Also, let us know if you
> have an interest in a port even though you cannot actually do the work
> to confirm it; that may encourage someone else to volunteer.
> 
> _  FreeBSD/2.2.1,2.2.5 - in progress (Tatsuo)

	FreeBSD 2.x and 3.x are the current working models, with 2.x being
our "stable" distribution, while 3.x is our development one.  From what
I'm seeing, 3.x looks like it might be moving towards a release, as we're
starting to generate snapshot's of that also, but I'm not sure.

	From my experience so far, 2.x and 3.x operate the same way as far
as PostgreSQL is concerned, as I'm running development under 3.x, but my
production platform is under 2.x...

> ?  NetBSD/i386 version? - not yet tested but should work?

	If I can remember my password on the machine in question, I'll get
online and do a compile/regression test on the i386 model this
afternoon...

> _  solaris/i386 - confirmed working (Marc)
> *  solaris/sparc/2.5.1 - confirmed working (Marc)
> _  solaris/sparc/2.6 - in progress (Tatsuo)

	confirmed working...its my model machine at the office, and what
the regression.SunOS file under src/test/regress is based off of...

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Sat, 14 Feb 1998 13:45:34 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Valid ports for v6.3
In message <34E5CE64.BA99E3D0@alumni.caltech.edu>, "Thomas G. Lockhart" writes:
> Here is my current list for porting status for the v6.3 release. I may
> have missed at least a few reports, e.g hpux, irix??
> 
> Since the porting support has changed for v6.3, if a system is not
> tested it should be assumed to be broken. Any regression test done since
> Feb 1 will count as "confirmed working", as long as the test ran to
> completion and for the most part behaved properly.
> 
> Any machine which does not get an installation and a regression test for
> v6.3beta will move to the unsupported list. Also, let us know if you
> have an interest in a port even though you cannot actually do the work
> to confirm it; that may encourage someone else to volunteer.
> 
> Marc/Bruce, can you help me clarify the bsdi/freebsd/netbsd/bsdxxx
> entries? I'm not sure which are unique and what the names should be...
> 
>                                                        - Tom
> 
> *  aix/4.1.4.0-4.2 - confirmed working when built on 4.1.4.0 (Darren
> King)
> _  aix/3.5 - not yet tested? close enough to 4.1 to count?? (Frank
> Dana?)
> _  bsdi
> _  FreeBSD/2.2.1,2.2.5 - in progress (Tatsuo)
> ?  NetBSD/i386 version? - not yet tested but should work?
> x  NetBSD/m68k Amiga, HP300, Mac - not yet working... (Henry Hotz)
> *  NetBSD/sparc version? confirmed working (Tom Helbekkmo)
> *  NetBSD/vax version? confirmed working (Tom Helbekkmo)
> *  dgux/5.4R4.11 - patches submitted (Brian Gallew)
> _  hpux/9.0.x
> _  hpux/10.20
> _  irix5
> _  irix6/MIPS
> _  dec/alpha - currently broken? confirmed working on v6.2.1 (Pedro)
> _  linux/alpha - currently broken?
> *  linux/i386 - confirmed working (Thomas)
> ?  linux/i386/glibc2 - minor library breakage; in progress (Oliver)
> _  mklinux/ppc - in progress (Tatsuo)
> _  nextstep - worked with patches on v1.0.9; not working now?
> _  sco/i386
> _  solaris/i386 - confirmed working (Marc)
> *  solaris/sparc/2.5.1 - confirmed working (Marc)
> _  solaris/sparc/2.6 - in progress (Tatsuo)
> _  sunos/sparc/4.1.4 - in progress (Tatsuo)
> _  svr4/MIPS - dcosx and sinix/seimens-nixdorf worked on v6.1 (Frank
> Ridderbusch?)
> _  ultrix4 - no recent reports? obsolete port??
> x  univel - not working now; in progress? (Billy G. Allie)
> 
> 

I don't see linux/sparc here.  The last snapshot I tried was from 2/6.
That ran well.  I just grapped today's (2/14) snapshot and will try that,
and let you know.  I'm using 2.0.29 kernel. 

One issue I've heard of is that _SC_OPEN_MAX is used in 
backend/storage/file/fd.c. I later kernels, /usr/include/asm/unistd.h
was changed. _SC_OPEN_MAX has #ifdef __KERNEL__ around it.  2.0.29 
doesn't have the #ifdef, so I don't have this issue.

I'm not what the correct fix should be.

Tom Szybist
szybist@boxhill.com

Sat, 14 Feb 1998 15:49:14 -0500
"Thomas A. Szybist" <szybist@boxhill.com>
Re: [HACKERS] Valid ports for v6.3 
> Here is my current list for porting status for the v6.3 release. I may
> have missed at least a few reports, e.g hpux, irix??
> 
> x  univel - not working now; in progress? (Billy G. Allie)
> 
Yes, it's currently being worked on.
-- 
____       | 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    | 



Sat, 14 Feb 1998 16:55:40 -0500
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] Valid ports for v6.3 
   ?  NetBSD/i386 version? - not yet tested but should work?

I'm trying to compile 6.3 on NetBSD/i386 v1.3.  A couple of problems
crop up with the compile.  I get the following warnings/errors:

     ... (lots of stuff deleted from compilation output) ...

     gmake[2]: Entering directory `/usr/local/NetBSD/pkgsrc/databases/postgresql/work/pgsql/src/backend/bootstrap'
     /usr/bin/yacc -d bootparse.y
     grep -v "^#" boot.sed > sedfile
     sed -f sedfile < y.tab.c > bootparse.c
     mv y.tab.h bootstrap_tokens.h
     rm -f y.tab.c sedfile
     gcc -I../../include -I../../backend -I/usr/local/include -O2 -pipe  -Wall -Wmissing-prototypes -I..    -Wno-error   -c bootparse.c -o bootparse.o
     y.tab.c: In function `Int_yyparse':
     y.tab.c:378: warning: implicit declaration of function `Int_yylex'
     y.tab.c:417: warning: implicit declaration of function `Int_yyerror'
     flex bootscanner.l
     grep -v "^#" boot.sed > sedfile
     sed -f sedfile < lex.yy.c > bootscanner.c
     rm -f lex.yy.c sedfile
     gcc -I../../include -I../../backend -I/usr/local/include -O2 -pipe  -Wall -Wmissing-prototypes -I..    -Wno-error   -c bootscanner.c -o bootscanner.o
     lex.Int_yy.c:683: warning: no previous prototype for `Int_yylex'
     bootscanner.l:137: warning: no previous prototype for `Int_yyerror'

     ... (lots of stuff deleted) ...

     gmake[2]: Entering directory `/usr/local/NetBSD/pkgsrc/databases/postgresql/work/pgsql/src/backend/parser'
     /usr/bin/yacc -d gram.y
     /usr/bin/yacc: f - maximum table size exceeded
     gmake[2]: *** [parse.h] Error 2
     /usr/bin/yacc -d gram.y
     /usr/bin/yacc: f - maximum table size exceeded
     gmake[2]: *** [gram.c] Error 2

Both sets of problems seem to relate to processing parsers with yacc.
Do I need bison instead?  If so, perhaps this should be listed as a
requirement in the INSTALL docs.

Thanks for your help.  I'll verify this port as soon as I resolve the
parser problems.

Cheers,
Brook





Sat, 14 Feb 1998 16:10:12 -0700 (MST)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile errors
On Sat, 14 Feb 1998, Brook Milligan wrote:

>    ?  NetBSD/i386 version? - not yet tested but should work?
> 
> I'm trying to compile 6.3 on NetBSD/i386 v1.3.  A couple of problems
> crop up with the compile.  I get the following warnings/errors:
> 
>      ... (lots of stuff deleted from compilation output) ...
> 
>      gmake[2]: Entering directory `/usr/local/NetBSD/pkgsrc/databases/postgresql/work/pgsql/src/backend/bootstrap'
>      /usr/bin/yacc -d bootparse.y
>      grep -v "^#" boot.sed > sedfile
>      sed -f sedfile < y.tab.c > bootparse.c
>      mv y.tab.h bootstrap_tokens.h
>      rm -f y.tab.c sedfile
>      gcc -I../../include -I../../backend -I/usr/local/include -O2 -pipe  -Wall -Wmissing-prototypes -I..    -Wno-error   -c bootparse.c -o bootparse.o
>      y.tab.c: In function `Int_yyparse':
>      y.tab.c:378: warning: implicit declaration of function `Int_yylex'
>      y.tab.c:417: warning: implicit declaration of function `Int_yyerror'
>      flex bootscanner.l
>      grep -v "^#" boot.sed > sedfile
>      sed -f sedfile < lex.yy.c > bootscanner.c
>      rm -f lex.yy.c sedfile
>      gcc -I../../include -I../../backend -I/usr/local/include -O2 -pipe  -Wall -Wmissing-prototypes -I..    -Wno-error   -c bootscanner.c -o bootscanner.o
>      lex.Int_yy.c:683: warning: no previous prototype for `Int_yylex'
>      bootscanner.l:137: warning: no previous prototype for `Int_yyerror'

	These "prototype" errors are normal and can safely be ignored...

>      ... (lots of stuff deleted) ...
> 
>      gmake[2]: Entering directory `/usr/local/NetBSD/pkgsrc/databases/postgresql/work/pgsql/src/backend/parser'
>      /usr/bin/yacc -d gram.y
>      /usr/bin/yacc: f - maximum table size exceeded
>      gmake[2]: *** [parse.h] Error 2
>      /usr/bin/yacc -d gram.y
>      /usr/bin/yacc: f - maximum table size exceeded
>      gmake[2]: *** [gram.c] Error 2

	Requires bison to be installed instead of yacc...

> Both sets of problems seem to relate to processing parsers with yacc.
> Do I need bison instead?  If so, perhaps this should be listed as a
> requirement in the INSTALL docs.

	It doesn't appear to be a seperate requirement on all systems...

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Sat, 14 Feb 1998 20:48:34 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile
	errors
> 	Requires bison to be installed instead of yacc...
> 
> > Both sets of problems seem to relate to processing parsers with yacc.
> > Do I need bison instead?  If so, perhaps this should be listed as a
> > requirement in the INSTALL docs.
> 
> 	It doesn't appear to be a seperate requirement on all systems...

Needed on bsdi.  I recommend we make it come with the distribution like
we do with scan.c.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Sat, 14 Feb 1998 20:16:25 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile
	errors
> >      gmake[2]: Entering directory `/usr/local/NetBSD/pkgsrc/databases/postgresql/work/pgsql/src/backend/parser'
> >      /usr/bin/yacc -d gram.y
> >      /usr/bin/yacc: f - maximum table size exceeded
> >      gmake[2]: *** [parse.h] Error 2
> >      /usr/bin/yacc -d gram.y
> >      /usr/bin/yacc: f - maximum table size exceeded
> >      gmake[2]: *** [gram.c] Error 2
>
>         Requires bison to be installed instead of yacc...
>
> > Both sets of problems seem to relate to processing parsers with yacc.
> > Do I need bison instead?  If so, perhaps this should be listed as a
> > requirement in the INSTALL docs.
>
>         It doesn't appear to be a seperate requirement on all systems...

Stan Brown suggested trying a -N switch (not sure which system he got this from):

        -N<secondary><n>
                Allow the sizes of certain internal yacc tables to
                be reset.  secondary is one of the letters from
                the set {B a m s p n e c l w} and specifies the
                table; n is the new size.  Tables that can be
                reset by using secondary letters are as follows:
                 a       a-array size; default is 12000.
                 m       mem array size; default is 12000
                 s       number of states; default is 1000.
                 p       number of productions; default is
                                  800
                n       number of non-terminals; default is
                                600.
                e       temp-space size; default is 1250.
                c       name-space size; default is 5000.
                l       look-ahead set table size; default i
                                650.
                w       working set table size; default is
                                650.

It would be great if someone would show exactly what is needed for the BSD yacc systems to avoid a requirement for bison. The problem is that in the last
couple of weeks the parser finally grew to exceed some internal limit in BSD yacc. Any solution might be applicable to other yacc'ers...

Also, if this fails we can try packaging "gram.c" with the distribution; I think that bison is similar to flex in generating library-independent C code. Would
like to resolve this in the next few days...

                                                   - Tom


Sun, 15 Feb 1998 01:19:49 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile
	errors
   > >      gmake[2]: Entering directory `/usr/local/NetBSD/pkgsrc/databases/postgresql/work/pgsql/src/backend/parser'
   > >      /usr/bin/yacc -d gram.y
   > >      /usr/bin/yacc: f - maximum table size exceeded
   > >      gmake[2]: *** [parse.h] Error 2
   > >      /usr/bin/yacc -d gram.y
   > >      /usr/bin/yacc: f - maximum table size exceeded
   > >      gmake[2]: *** [gram.c] Error 2
   >
   >         Requires bison to be installed instead of yacc...
   >
   > > Both sets of problems seem to relate to processing parsers with yacc.
   > > Do I need bison instead?  If so, perhaps this should be listed as a
   > > requirement in the INSTALL docs.
   >
   >         It doesn't appear to be a seperate requirement on all systems...

   Stan Brown suggested trying a -N switch (not sure which system he got this from):

At least on NetBSD/i386 v1.3 yacc does not have a -N switch.

   Also, if this fails we can try packaging "gram.c" with the
   distribution; I think that bison is similar to flex in generating
   library-independent C code. 

This seems to be the best solution.  The situation with flex and yacc
is much the same as with the configuration system.  These programs
take specs and generate compilable files that should be system
independent (am I wrong about that last point?).  Just as we don't
require people to have the autoconf tool to generate the configure
script, perhaps we shouldn't require flex or bison either.  Of course,
the original lexer and parser files should be shipped as well for
completeness, just as configure.in is.

Just my thoughts.  I'll get bison in the meantime so I can do the
testing.

Cheers,
Brook


Sat, 14 Feb 1998 22:17:22 -0700 (MST)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile
	errors
On Sat, 14 Feb 1998, Thomas G. Lockhart wrote:

> Here is my current list for porting status for the v6.3 release. I may
> have missed at least a few reports, e.g hpux, irix??
...
> _  linux/alpha - currently broken?

	Linux/Alpha is indeed currently broken (i.e. I would not use it
yet for production work), but getting better every day! :)

----------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                     |
|                                            --- Philippians 1:21 (KJV)    |
----------------------------------------------------------------------------
|  Ryan Kirkpatrick  |  Boulder, Colorado  | rkirkpat@nag.cs.colorado.edu  |
----------------------------------------------------------------------------
|               http://www-ugrad.cs.colorado.edu/~rkirkpat/                |
----------------------------------------------------------------------------



Sun, 15 Feb 1998 12:11:29 -0600 (CST)
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Re: [HACKERS] Valid ports for v6.3