byacc problem with FreeBSD ...

Started by The Hermit Hackerover 25 years ago7 messages
#1The Hermit Hacker
scrappy@hub.org

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: The Hermit Hacker (#1)
Re: byacc problem with FreeBSD ...

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

#3The Hermit Hacker
scrappy@hub.org
In reply to: Tom Lane (#2)
Re: byacc problem with FreeBSD ...

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: The Hermit Hacker (#3)
Re: byacc problem with FreeBSD ...

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

#5Alfred Perlstein
bright@wintelcom.net
In reply to: Tom Lane (#2)
Re: byacc problem with FreeBSD ...

* 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."

#6The Hermit Hacker
scrappy@hub.org
In reply to: Tom Lane (#4)
Re: byacc problem with FreeBSD ...

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*

#7The Hermit Hacker
scrappy@hub.org
In reply to: Alfred Perlstein (#5)
Re: byacc problem with FreeBSD ...

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