Thread: preproc.y error
In today's (2/7/2k1) snapshot from hub, I'm getting this: gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -I./../include -DMAJOR_VERSION=2 -DMINOR_VERSION=8 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/usr/local/pgsql/include\" -c -o preproc.o preproc.c preproc.y:3957: syntax error at null character I'm not 100% convinced that it's not something squirrelly with this machine. But it's a brand new FreeBSD 4.2-R installation. I haven't tried building a kernel yet with it but the postgres compile hasn't gone without bumps which is why I'm suspicious. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> In today's (2/7/2k1) snapshot from hub, I'm getting this:
> gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
> -I../../../../src/include -I./../include -DMAJOR_VERSION=2 -DMINOR_VERSION=8 -DPATCHLEVEL=0
> -DINCLUDE_PATH=\"/usr/local/pgsql/include\" -c -o preproc.o preproc.c
> preproc.y:3957: syntax error at null character
Works fine here, and there's nothing visibly wrong with line 3957 and
neighbors in my copy. Try removing preproc.c and letting the system
rebuild it.
regards, tom lane
On Wed, 7 Feb 2001, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > In today's (2/7/2k1) snapshot from hub, I'm getting this: > > > gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations > > -I../../../../src/include -I./../include -DMAJOR_VERSION=2 -DMINOR_VERSION=8 -DPATCHLEVEL=0 > > -DINCLUDE_PATH=\"/usr/local/pgsql/include\" -c -o preproc.o preproc.c > > preproc.y:3957: syntax error at null character > > Works fine here, and there's nothing visibly wrong with line 3957 and > neighbors in my copy. Try removing preproc.c and letting the system > rebuild it. Now I get: byacc -d preproc.y byacc: f - maximum table size exceeded gmake[4]: *** [preproc.c] Error 2 However it failed building a kernel, I may have some bad ram. I'm supposed to have 256M coming any day - actually I thought it'd be here by now. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> Now I get:
> byacc -d preproc.y
> byacc: f - maximum table size exceeded
> gmake[4]: *** [preproc.c] Error 2
Better install bison if you want to work with CVS sources ...
the lack of bison probably explains why it's failing for you on
this system when it's OK on other FreeBSD boxes.
I wonder if we ought not accept byacc as a suitable yacc in configure?
Peter, what do you think?
regards, tom lane
BTW, I pulled down the current snapshot, and there doesn't seem to be
anything wrong with preproc.c in it. So the lack of bison on your
machine wasn't the issue anyway; it should've compiled the preproc.c
from the snapshot without complaint.
It does sound like there may be some outright flakiness in your new
machine :-(
regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [010207 17:24] wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > Now I get: > > byacc -d preproc.y > > byacc: f - maximum table size exceeded > > gmake[4]: *** [preproc.c] Error 2 > > Better install bison if you want to work with CVS sources ... > the lack of bison probably explains why it's failing for you on > this system when it's OK on other FreeBSD boxes. > > I wonder if we ought not accept byacc as a suitable yacc in configure? > Peter, what do you think? I think I reported this broken a couple of months ago, but it was too late to add the check to configure for 7.0. byacc doesn't work, you need bison (or maybe some special flags to byacc). -- -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 Wed, 7 Feb 2001, Tom Lane wrote: > BTW, I pulled down the current snapshot, and there doesn't seem to be > anything wrong with preproc.c in it. So the lack of bison on your > machine wasn't the issue anyway; it should've compiled the preproc.c > from the snapshot without complaint. > > It does sound like there may be some outright flakiness in your new > machine :-( Hopefully the new ram will show tomorrow. I need to build a kernel and know enough to not bother with one built on bad ram. Thanks for the double check. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On 07 Feb 2001 at 20:15 (-0500), Tom Lane wrote: | Vince Vielhaber <vev@michvhf.com> writes: | > Now I get: | > byacc -d preproc.y | > byacc: f - maximum table size exceeded | > gmake[4]: *** [preproc.c] Error 2 | | Better install bison if you want to work with CVS sources ... | the lack of bison probably explains why it's failing for you on | this system when it's OK on other FreeBSD boxes. I concur that bison is required -- A fresh OpenBSD install failed to build with the same error mentioned above until I installed bison. | I wonder if we ought not accept byacc as a suitable yacc in configure? | Peter, what do you think? I can agree with this approach, unless there is some magic to get byacc to work. In any case, there should be a note in the installation docs stating that bison must be used when working with the CVS src. brent
Brent Verner <brent@rcfile.org> writes:
> | I wonder if we ought not accept byacc as a suitable yacc in configure?
> I can agree with this approach, unless there is some magic to get
> byacc to work.
It's very probably possible to make it work by feeding byacc enough
table-enlarging options. (I have some now-outdated notes in the
FAQ_HPUX doc file about what options are needed to build with the
vendor's yacc on HPUX.) However, I don't think we want to bother with
trying to maintain a workable set of byacc options in the makefiles.
They'd not get enough testing, since the developers all have bison
installed and most other people use tarballs in which the parser files
are prebuilt. So it seems to me that the right approach is for
configure to never select byacc or yacc by default, but instead to
use a 'missing' script like we do when flex isn't found. As with the
flex case, the user could override configure's choice, but if he does
then it's his problem to make it work.
regards, tom lane
Brent Verner writes: > I can agree with this approach, unless there is some magic to get > byacc to work. In any case, there should be a note in the installation > docs stating that bison must be used when working with the CVS src. There is. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Tom Lane writes: > So it seems to me that the right approach is for configure to never > select byacc or yacc by default, but instead to use a 'missing' script > like we do when flex isn't found. As with the flex case, the user > could override configure's choice, but if he does then it's his > problem to make it work. I like that. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/