Hi,

I'm trying to build cvs, but it fails:

bison -y -d  preproc.y
preproc.y:6214: fatal error: maximum table size (32767) exceeded
make[4]: *** [preproc.h] Error 1
make[4]: Leaving directory
`/home/bert/src/pgsql/src/interfaces/ecpg/preproc'

What's the problem?

-- 
Markus Bertheau.
Berlin, Berlin.
Germany.

01 Jul 2003 21:39:59 +0200
Markus Bertheau <twanger@bluetwanger.de>
cvs build failure
what version of bison are you using?  I believe we require 1.875 these days.

LER

--On Tuesday, July 01, 2003 21:39:59 +0200 Markus Bertheau 
<twanger@bluetwanger.de> wrote:

> Hi,
>
> I'm trying to build cvs, but it fails:
>
> bison -y -d  preproc.y
> preproc.y:6214: fatal error: maximum table size (32767) exceeded
> make[4]: *** [preproc.h] Error 1
> make[4]: Leaving directory
> `/home/bert/src/pgsql/src/interfaces/ecpg/preproc'
>
> What's the problem?



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749




Tue, 01 Jul 2003 14:41:32 -0500
Larry Rosenman <ler@lerctr.org>
Re: cvs build failure
В Втр, 01.07.2003, в 21:41, Larry Rosenman пишет:
> what version of bison are you using?  I believe we require 1.875 these days.

1.35. I'll upgrade. Thanks.

-- 
Markus Bertheau.
Berlin, Berlin.
Germany.

01 Jul 2003 21:44:37 +0200
Markus Bertheau <twanger@bluetwanger.de>
Re: cvs build failure
On Tue, Jul 01, 2003 at 09:39:59PM +0200, Markus Bertheau wrote:

> bison -y -d  preproc.y
> preproc.y:6214: fatal error: maximum table size (32767) exceeded
> make[4]: *** [preproc.h] Error 1
> make[4]: Leaving directory
> `/home/bert/src/pgsql/src/interfaces/ecpg/preproc'
> 
> What's the problem?

You need to install bison-1.875 or later.  I think there were RPMs on
www.joeconway.com if you are in a Redhat-ish system, or you can get it
from GNU ftp's if you are not.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La conclusion que podemos sacar de esos estudios es que
no podemos sacar ninguna conclusion de ellos" (Tanenbaum)

Tue, 1 Jul 2003 15:45:12 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: cvs build failure

CVS checks for an old bison, though it just throws a warning, not an
error.

---------------------------------------------------------------------------

Markus Bertheau wrote:
> ? ???, 01.07.2003, ? 21:41, Larry Rosenman ?????:
> > what version of bison are you using?  I believe we require 1.875 these days.
> 
> 1.35. I'll upgrade. Thanks.
> 
> -- 
> Markus Bertheau.
> Berlin, Berlin.
> Germany.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 1 Jul 2003 15:55:30 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs build failure
Markus Bertheau <twanger@bluetwanger.de> writes:
>> what version of bison are you using?  I believe we require 1.875 these days.

> 1.35. I'll upgrade. Thanks.

I believe 'configure' will bleat about a too-old bison, but it won't
refuse to proceed --- and the warning is easy to miss in the pages of
output that configure produces.

I was against having configure error out if bison is too old, since
you might not need it at all (if building from a tarball).  But it
seems like we still have the problem.

Maybe make configure act as though bison is missing?  Not sure.  It
seems like that could create unnecessary problems in other cases.

			regards, tom lane

Tue, 01 Jul 2003 18:12:31 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs build failure 
On Tue, Jul 01, 2003 at 06:12:31PM -0400, Tom Lane wrote:
> 
> I believe 'configure' will bleat about a too-old bison, but it won't
> refuse to proceed --- and the warning is easy to miss in the pages of
> output that configure produces.

Maybe it should throw an error and refuse to continue if the version is
too old, but the message be verbose enough to let the user know of a
separate switch to configure that would allow it to continue the
configuration ignoring the bison version.

Somethink like
$ ./configure
error: your bison is too old.  Use --ignore-bison if you don't need it
$ ./configure --ignore-bison
[succeeds]

I've seen similar things in other projects...

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Major Fambrough: You wish to see the frontier?
John Dunbar: Yes sir, before it's gone.

Tue, 1 Jul 2003 18:29:27 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: cvs build failure
Tom Lane wrote:
> Markus Bertheau <twanger@bluetwanger.de> writes:
> >> what version of bison are you using?  I believe we require 1.875 these days.
> 
> > 1.35. I'll upgrade. Thanks.
> 
> I believe 'configure' will bleat about a too-old bison, but it won't
> refuse to proceed --- and the warning is easy to miss in the pages of
> output that configure produces.
> 
> I was against having configure error out if bison is too old, since
> you might not need it at all (if building from a tarball).  But it
> seems like we still have the problem.
> 
> Maybe make configure act as though bison is missing?  Not sure.  It
> seems like that could create unnecessary problems in other cases.

One trick would be to set YACC to some special value like
"bison.too.old" and test for that when YACC is actually called from the
Makefile.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 1 Jul 2003 18:38:54 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs build failure

Usual installs don't need bison because the tarball has pregenerated
bison output files.

---------------------------------------------------------------------------

Alvaro Herrera wrote:
> On Tue, Jul 01, 2003 at 06:12:31PM -0400, Tom Lane wrote:
> > 
> > I believe 'configure' will bleat about a too-old bison, but it won't
> > refuse to proceed --- and the warning is easy to miss in the pages of
> > output that configure produces.
> 
> Maybe it should throw an error and refuse to continue if the version is
> too old, but the message be verbose enough to let the user know of a
> separate switch to configure that would allow it to continue the
> configuration ignoring the bison version.
> 
> Somethink like
> $ ./configure
> error: your bison is too old.  Use --ignore-bison if you don't need it
> $ ./configure --ignore-bison
> [succeeds]
> 
> I've seen similar things in other projects...
> 
> -- 
> Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
> Major Fambrough: You wish to see the frontier?
> John Dunbar: Yes sir, before it's gone.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 1 Jul 2003 18:40:36 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs build failure
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Maybe make configure act as though bison is missing?  Not sure.  It
>> seems like that could create unnecessary problems in other cases.

> One trick would be to set YACC to some special value like
> "bison.too.old" and test for that when YACC is actually called from the
> Makefile.

I kinda like Alvaro's suggestion of an --ignore-bison-version option
to configure to suppress checking the version, but otherwise error out
if we think bison is too old.

The advantage to that is that you could manually override the automatic
check if you had reason to know it was wrong (eg, you could see it'd
misparsed the bison version string, or something).  Also, it'd make
sense to include that option by default in RPM builds, where you'd know
you had up-to-date bison output files already included in the SRPM.

			regards, tom lane

Tue, 01 Jul 2003 18:42:35 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs build failure 
Larry Rosenman <ler@lerctr.org> writes:

> what version of bison are you using?  I believe we require 1.875
> these days.

It would be nice to be able to say --without-ecpg at configure time.
Ecpg is the only part of pg that requires this version of bison and
and is not a core part of the project, or is it?

Regards,
Manuel.

01 Jul 2003 17:48:30 -0500
Manuel Sugawara <masm@fciencias.unam.mx>
Re: cvs build failure
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Maybe make configure act as though bison is missing?  Not sure.  It
> >> seems like that could create unnecessary problems in other cases.
> 
> > One trick would be to set YACC to some special value like
> > "bison.too.old" and test for that when YACC is actually called from the
> > Makefile.
> 
> I kinda like Alvaro's suggestion of an --ignore-bison-version option
> to configure to suppress checking the version, but otherwise error out
> if we think bison is too old.
> 
> The advantage to that is that you could manually override the automatic
> check if you had reason to know it was wrong (eg, you could see it'd
> misparsed the bison version string, or something).  Also, it'd make
> sense to include that option by default in RPM builds, where you'd know
> you had up-to-date bison output files already included in the SRPM.

I can see making a new bison required only when the version is *devel. 
That way, folks testing CVS and even the *devel snapshots would need a
new bison, but our normal users wouldn't.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 1 Jul 2003 18:55:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs build failure
В Срд, 02.07.2003, в 00:42, Tom Lane пишет:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Maybe make configure act as though bison is missing?  Not sure.  It
> >> seems like that could create unnecessary problems in other cases.
> 
> > One trick would be to set YACC to some special value like
> > "bison.too.old" and test for that when YACC is actually called from the
> > Makefile.
> 
> I kinda like Alvaro's suggestion of an --ignore-bison-version option
> to configure to suppress checking the version, but otherwise error out
> if we think bison is too old.
> 
> The advantage to that is that you could manually override the automatic
> check if you had reason to know it was wrong (eg, you could see it'd
> misparsed the bison version string, or something).  Also, it'd make
> sense to include that option by default in RPM builds, where you'd know
> you had up-to-date bison output files already included in the SRPM.

But it seems weird to require a switch for the normal case, i.e. a
tarball build, and not require it for a cvs build. I don't see
overriding as an advantage, too, because misparsing of the bison version
string would just be a bug that had to be fixed, imo. You can as well
modify configure in that case to make it compile, and send the patch to
the bison version parser in afterwards.

Maybe add a comment to the Makefile where bison is called that gives a
hint to the user in case bison fails.

-- 
Markus Bertheau.
Berlin, Berlin.
Germany.

02 Jul 2003 00:56:11 +0200
Markus Bertheau <twanger@bluetwanger.de>
Re: cvs build failure
On Wed, Jul 02, 2003 at 12:56:11AM +0200, Markus Bertheau wrote:

> But it seems weird to require a switch for the normal case, i.e. a
> tarball build, and not require it for a cvs build.

Yeah, I agree.  Maybe the configure script should be built different for
the releases, so users downloading tarballs don't need to use a switch,
but people getting from CVS or snapshots do.

> Maybe add a comment to the Makefile where bison is called that gives a
> hint to the user in case bison fails.

Not too many people read Makefiles these days, specially when autotools
are involved (BTW, Postgres makefiles are very nice, but I don't think
people reads them anyway).  What would be the user looking for?  The
symbol in question is called $(YACC), perhaps not too intuitive.

Another suggestion would be to capture bison's error code for the
table-too-large error and give an informational message about bison
version.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Ni aun el genio muy grande llegaria muy lejos
si tuviera que sacarlo todo de su propio interior" (Goethe)

Tue, 1 Jul 2003 19:10:06 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: cvs build failure
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I can see making a new bison required only when the version is *devel. 
> That way, folks testing CVS and even the *devel snapshots would need a
> new bison, but our normal users wouldn't.

Even then, if they're using a snapshot they shouldn't need it.

Perhaps a combination of your idea and Alvaro's: set things up so that
we fail only when bison is actually invoked by the makefiles, plus
provide a way to override the version check if it's wrong.

			regards, tom lane

Tue, 01 Jul 2003 19:10:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs build failure 
В Срд, 02.07.2003, в 01:10, Alvaro Herrera пишет:
> On Wed, Jul 02, 2003 at 12:56:11AM +0200, Markus Bertheau wrote:
>
> > Maybe add a comment to the Makefile where bison is called that gives a
> > hint to the user in case bison fails.
> 
> Not too many people read Makefiles these days

Sorry, I meant an echo statement to communicate that message to stdout.

> Another suggestion would be to capture bison's error code for the
> table-too-large error and give an informational message about bison
> version.
-- 
Markus Bertheau.
Berlin, Berlin.
Germany.

02 Jul 2003 01:16:09 +0200
Markus Bertheau <twanger@bluetwanger.de>
Re: cvs build failure

Is it not possible to check when configure is run for the presence of the
bison output files, and only fail if one or more is absent and the bison
version is too low?

just a thought.

andrew

----- Original Message ----- 
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Markus Bertheau" <twanger@bluetwanger.de>; "Larry Rosenman"
<ler@lerctr.org>; <pgsql-hackers@postgresql.org>
Sent: Tuesday, July 01, 2003 7:10 PM
Subject: Re: [HACKERS] cvs build failure


> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I can see making a new bison required only when the version is *devel.
> > That way, folks testing CVS and even the *devel snapshots would need a
> > new bison, but our normal users wouldn't.
>
> Even then, if they're using a snapshot they shouldn't need it.
>
> Perhaps a combination of your idea and Alvaro's: set things up so that
> we fail only when bison is actually invoked by the makefiles, plus
> provide a way to override the version check if it's wrong.
>
> regards, tom lane
>


Tue, 1 Jul 2003 20:09:23 -0400
"Andrew Dunstan" <andrew@dunslane.net>
Re: cvs build failure 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I can see making a new bison required only when the version is *devel. 
> > That way, folks testing CVS and even the *devel snapshots would need a
> > new bison, but our normal users wouldn't.
> 
> Even then, if they're using a snapshot they shouldn't need it.
> 
> Perhaps a combination of your idea and Alvaro's: set things up so that
> we fail only when bison is actually invoked by the makefiles, plus
> provide a way to override the version check if it's wrong.

I don't see a reason to have a flag to turn it off --- has anyone
reported that the version check failed?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 1 Jul 2003 20:37:30 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs build failure
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I don't see a reason to have a flag to turn it off --- has anyone
> reported that the version check failed?

Since that version check has only been in CVS tip a month or two, and
has not seen a release cycle, it'd be folly to think it's bulletproof.

			regards, tom lane

Tue, 01 Jul 2003 23:54:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs build failure 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I don't see a reason to have a flag to turn it off --- has anyone
> > reported that the version check failed?
> 
> Since that version check has only been in CVS tip a month or two, and
> has not seen a release cycle, it'd be folly to think it's bulletproof.

But do we add the ability to turn it off when we have no evidence it
will ever be needed, and if we hook it only to *devel versions?

This would turn off the make failure when an old bison is called from
the makefile?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 2 Jul 2003 00:21:36 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs build failure
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> This would turn off the make failure when an old bison is called from
> the makefile?

Rephrase that as "this would give bison the right to fail of its own
accord, rather than our prejudging its ability to cope."

Given bison's on-again-off-again track record in recent releases,
I don't think it's wise to wire in a non-overridable assumption
that bison < X is broken and bison >= X is good.  A hint that
bison < X might be broken is fine --- but let's not pretend that
configure is smarter than the user.

			regards, tom lane

Wed, 02 Jul 2003 00:45:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvs build failure 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > This would turn off the make failure when an old bison is called from
> > the makefile?
> 
> Rephrase that as "this would give bison the right to fail of its own
> accord, rather than our prejudging its ability to cope."
> 
> Given bison's on-again-off-again track record in recent releases,
> I don't think it's wise to wire in a non-overridable assumption
> that bison < X is broken and bison >= X is good.  A hint that
> bison < X might be broken is fine --- but let's not pretend that
> configure is smarter than the user.

I just don't like to add bloat/document another configure option that
has a _very_ limited usefulness.  Can we not document it and just print
it when we report the bison failure?  Should we just allow an environment
variable to over-ride it?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 2 Jul 2003 00:56:05 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: cvs build failure