Thread: 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??

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)

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

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

> 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    |

?  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

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

>     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

> >      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
otheryacc'ers... 

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

                                                   - Tom

   > >      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

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