Thread: byacc problem with FreeBSD ...
Just going through Peter's new 'mk-snapshot' script, and found a problem:
gmake[4]: Entering directory `/home/projects/pgsql/snapshot/pgsql/postgresql-snapshot/src/backend/parser'
byacc -d gram.y
byacc: f - maximum table size exceeded
gmake[4]: *** [gram.c] Error 2
gmake[4]: Leaving directory `/home/projects/pgsql/snapshot/pgsql/postgresql-snapshot/src/backend/parser'
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> Just going through Peter's new 'mk-snapshot' script, and found a problem:
> gmake[4]: Entering directory `/home/projects/pgsql/snapshot/pgsql/postgresql-snapshot/src/backend/parser'
> byacc -d gram.y
> byacc: f - maximum table size exceeded
byacc? Why isn't it using bison?
regards, tom lane
damn ... I thought that our configure refused anything *but* bison? how come its allowying me to use byacc? :) On Mon, 25 Sep 2000, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > Just going through Peter's new 'mk-snapshot' script, and found a problem: > > > > gmake[4]: Entering directory `/home/projects/pgsql/snapshot/pgsql/postgresql-snapshot/src/backend/parser' > > byacc -d gram.y > > byacc: f - maximum table size exceeded > > gmake[4]: *** [gram.c] Error 2 > > gmake[4]: Leaving directory `/home/projects/pgsql/snapshot/pgsql/postgresql-snapshot/src/backend/parser' > > You don't have a bison binary installed on hub.org. > > hub:~$ which bison > hub:~$ locate bison > /home/share/info/bison.info.gz > /home/share/man/cat1/bison.1.gz > /home/share/man/man1/bison.1.gz > /home/share/misc/bison.hairy > /home/share/misc/bison.simple > /home/vhosts/kde.org/cvsroot/kdelibs/jscript/Attic/bison2cpp.h,v > /home/vhosts/kde.org/cvsroot/kdelibs/jscript/Attic/cpp2bison.cpp,v > /usr/ports/devel/bison > /usr/ports/devel/bison/Makefile > /usr/ports/devel/bison/files > /usr/ports/devel/bison/files/md5 > /usr/ports/devel/bison/patches > /usr/ports/devel/bison/patches/patch-getargs.c > /usr/ports/devel/bison/patches/patch-reader.c > /usr/ports/devel/bison/pkg > /usr/ports/devel/bison/pkg/COMMENT > /usr/ports/devel/bison/pkg/DESCR > /usr/ports/devel/bison/pkg/PLIST > > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> damn ... I thought that our configure refused anything *but* bison? how
> come its allowying me to use byacc? :)
I think it should try to use the system yacc if it can't find bison.
It is possible to build our grammar with non-bison yaccs, since we
aren't using any bison-only features (not true for lex/flex,
unfortunately).
Persuading the local yacc to enlarge its tables enough to accept our
grammar is an exercise for the user ;-). I have some notes about
making HPUX's yacc work in FAQ_HPUX.
But our distro should certainly use bison to build the derived files.
You used to have bison on hub.org, what happened to it?
regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [000925 08:11] wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > Just going through Peter's new 'mk-snapshot' script, and found a problem: > > > gmake[4]: Entering directory `/home/projects/pgsql/snapshot/pgsql/postgresql-snapshot/src/backend/parser' > > byacc -d gram.y > > byacc: f - maximum table size exceeded > > byacc? Why isn't it using bison? Because we no longer ship the GPL encumbered bison in the base system. I've mentioned this before. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
On Mon, 25 Sep 2000, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > damn ... I thought that our configure refused anything *but* bison? how > > come its allowying me to use byacc? :) > > I think it should try to use the system yacc if it can't find bison. > It is possible to build our grammar with non-bison yaccs, since we > aren't using any bison-only features (not true for lex/flex, > unfortunately). > > Persuading the local yacc to enlarge its tables enough to accept our > grammar is an exercise for the user ;-). I have some notes about > making HPUX's yacc work in FAQ_HPUX. > > But our distro should certainly use bison to build the derived files. > You used to have bison on hub.org, what happened to it? Not sure ... its in ports, and it isn't one that I can think of having ever removed *scratch head* And we haven't done any major hardware upgrades recently that would have caused me to rebuild /usr/local :( Maybe up until recently it actually squeeked by on byacc *shrug*
On Mon, 25 Sep 2000, Alfred Perlstein wrote: > * Tom Lane <tgl@sss.pgh.pa.us> [000925 08:11] wrote: > > The Hermit Hacker <scrappy@hub.org> writes: > > > Just going through Peter's new 'mk-snapshot' script, and found a problem: > > > > > gmake[4]: Entering directory `/home/projects/pgsql/snapshot/pgsql/postgresql-snapshot/src/backend/parser' > > > byacc -d gram.y > > > byacc: f - maximum table size exceeded > > > > byacc? Why isn't it using bison? > > Because we no longer ship the GPL encumbered bison in the base > system. I've mentioned this before. D'oh, tha twould explain why I didn't have it in /usr/local *nod* thanks alfred ...