[HACKERS] 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. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 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. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 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) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cvs build failure
Markus Bertheau [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 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. ---(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
Re: [HACKERS] cvs build failure
Tom Lane wrote: Markus Bertheau [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cvs build failure
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] cvs build failure
Larry Rosenman [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs build failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cvs build failure
, 02.07.2003, 00:42, Tom Lane : Bruce Momjian [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 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) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cvs build failure
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 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. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cvs build failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cvs build failure
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] cvs build failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cvs build failure
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cvs build failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
