Thread: cvs build failure
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.
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
В Втр, 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.
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)
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, Pennsylvania19073
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
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.
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, Pennsylvania19073
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, Pennsylvania19073
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
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.
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, Pennsylvania19073
В Срд, 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.
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)
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
В Срд, 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.
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 >
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, Pennsylvania19073
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
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, Pennsylvania19073
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
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, Pennsylvania19073