Thread
-
Valid ports for v6.3
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-14T17:03:32Z
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) -
Re: [HACKERS] Valid ports for v6.3
Marc G. Fournier <scrappy@hub.org> — 1998-02-14T17:45:34Z
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 -
Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile errors
Brook Milligan <brook@trillium.nmsu.edu> — 1998-02-14T23:10:12Z
? 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 -
Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile errors
Marc G. Fournier <scrappy@hub.org> — 1998-02-15T00:48:34Z
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 -
Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile errors
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-15T01:16:25Z
> 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
-
Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile errors
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-15T01:19:49Z
> > 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 -
Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile errors
Brook Milligan <brook@trillium.nmsu.edu> — 1998-02-15T05:17:22Z
> > 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
-
Re: [HACKERS] Valid ports for v6.3
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1998-02-15T18:11:29Z
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/ | ----------------------------------------------------------------------------