Thread: backend/parser compile prob
I'm getting far too many errors while trying to compile gram.c in the backend/parser, that I must be missing something.. Story so far gmake distclean cvs update configure --enable-debug --enable-cassert gmake gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser' gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include -c -o gram.o gram.c gram.y:105: parse error before `Attr' gram.y:105: warning: no semicolon at end of struct or union gram.y:109: parse error before `*' gram.y:109: warning: type defaults to `int' in declaration of `param' gram.y:109: warning: data definition has no type or storage class ... GNU Make version 3.79.1 % cvs diff src/backend/parser/gram.c % In other words, I'm not even regenerating gram.c with bison (GNU Bison) 1.875 flex version 2.5.4 Thoughts? Cheers, Patrick
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> I'm getting far too many errors while trying to compile gram.c in the
> backend/parser, that I must be missing something.
I think you need to force gram.c to be regenerated. Try removing it
(and parse.h too) before building.
> % cvs diff src/backend/parser/gram.c
gram.c is not in CVS. I'm surprised you didn't get an error from that.
(I get "cvs server: I know nothing about gram.c".)
regards, tom lane
On Tue, Jul 15, 2003 at 11:21:51AM -0400, Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: > > I'm getting far too many errors while trying to compile gram.c in the > > backend/parser, that I must be missing something. > > I think you need to force gram.c to be regenerated. Try removing it > (and parse.h too) before building. > > > % cvs diff src/backend/parser/gram.c > > gram.c is not in CVS. I'm surprised you didn't get an error from that. > (I get "cvs server: I know nothing about gram.c".) Ah: Attic: % cvs status gram.c =================================================================== File: gram.c Status: Up-to-date Working revision: 2.90 Repository revision: 2.90 /projects/cvsroot/pgsql-server/src/backend/parser/Attic/gram.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) hmm... rm gram.c parse.h scan.c gmake[3]: Leaving directory `/usr/src/local/pgsql/src/port' gmake -C parser parse.h gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser' bison -y -d gram.y mv -f y.tab.c ./gram.c mv -f y.tab.h ./parse.h gmake[3]: Leaving directory `/usr/src/local/pgsql/src/backend/parser' prereqdir=`cd parser/ >/dev/null && pwd` && \ cd ../../src/include/parser/ && rm -f parse.h && \ ln -s "$prereqdir/parse.h". gmake -C access all gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/access' ... gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/src/local/pgsql/src/backend/catalog' gmake -C parser all gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser' /usr/bin/flex -CF -o'scan.c' scan.l gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include -c -o gram.o gram.c In file included from gram.y:7990: scan.c:121: parse error before string constant scan.c:247: parse error before string constant scan.c:250: parse error before string constant scan.c:251: parse error before string constant ... What string constant?! Will try again later... Cheers, Patrick
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> /usr/bin/flex -CF -o'scan.c' scan.l
> gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include -c -o gram.o gram.c
> In file included from gram.y:7990:
> scan.c:121: parse error before string constant
> scan.c:247: parse error before string constant
> scan.c:250: parse error before string constant
> scan.c:251: parse error before string constant
> ...
> What string constant?! Will try again later...
Which flex version are you using? You need 2.5.4 --- the most recent
versions have broken backwards compatibility :-(. I'm not sure what the
symptom looks like, though.
regards, tom lane
On Tue, Jul 15, 2003 at 12:42:45PM -0400, Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: ... > > What string constant?! Will try again later... > > Which flex version are you using? You need 2.5.4 --- the most recent > versions have broken backwards compatibility :-(. I'm not sure what the > symptom looks like, though. Answer is: a broken flex 2.5.4. There were some commits to NetBSD flex to use bounded strings. Using 13th July flex source builds a happy PostgreSQL. Now to track down which bit broke - anyway, not a PostgreSQL problem :-) Cheers, Patrick ======================All 91 tests passed. ====================== NetBSD-1.6U/i386
On Wed, Jul 16, 2003 at 11:58:01PM +0900, itojun@iijlab.net wrote: > could you try lex/scan.l 1.13 i just committed? Yes, that fixed it! Cheers, Patrick
Can somebody clarify for me the requirement for the SHMSEG kernel parameter, please. The Postgres doc says: SHMSEG - Maximum number of shared memory segments per process only 1 segment is needed, but the default is much higher I was trying to calculate the kernel parameters for running a number of Postgres servers on Solaris, and something did not work. Having Postgres running I executed ipcs. It shows that while Postgres is taking only one segment, the number of attachments is 7. This I think refers to the number of processes spawned by postmaster at that time. Solaris docs describe SHMSEG as "Limit on the number of shared memory segments that any one process can create" Now run this: sysdef | grep SHMSEG -> 50 max attached shm segments per process (SHMSEG) I suppose there's a distinction between "can create" and "can attach to". Looks like the manual and output of sysdef are not very consistent. I am worried that maybe (on Solaris) SHMSEG should be set with respect to number of connections, rather than number of servers. Thank you, Mike.
>Answer is: a broken flex 2.5.4. There were some commits to NetBSD flex to >use bounded strings. Using 13th July flex source builds a happy PostgreSQL. >Now to track down which bit broke - anyway, not a PostgreSQL problem :-) could you try usr.bin/lex/initscan.c revision 1.16? itojun
>> could you try lex/scan.l 1.13 i just committed? >Yes, that fixed it! tnx for reporting! itojun