Connecting Tech Pros Worldwide Forums | Help | Site Map

tsearch2 in 7.4beta1 compile problem

Jeff Davis
Guest
 
Posts: n/a
#1: Nov 11 '05
After installing PostgreSQL 7.4 beta 1 from source, I decided to install the
/contrib module tsearch2.

I cd to the tsearch2 directory and typed "make", however I get an error that
yy_current_buffer is an undeclared identifier in wordparser/parser.c (which
is apparently autogenerated with flex from parser.l).

I looked online, and it seemed like I was building the module in the right
way. I also downloaded the latest development version, and that seemed to
fail in the same way.

Has anyone else had this problem? I'm using flex 2.5.31 and gcc 3.3.1.

Thanks,
Jeff


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly


Oleg Bartunov
Guest
 
Posts: n/a
#2: Nov 11 '05

re: tsearch2 in 7.4beta1 compile problem


This is a FAQ. Don't use flex 2.5.31
Downgrade to stable 2.5.4.

Oleg
On Wed, 13 Aug 2003, Jeff Davis wrote:
[color=blue]
> After installing PostgreSQL 7.4 beta 1 from source, I decided to install the
> /contrib module tsearch2.
>
> I cd to the tsearch2 directory and typed "make", however I get an error that
> yy_current_buffer is an undeclared identifier in wordparser/parser.c (which
> is apparently autogenerated with flex from parser.l).
>
> I looked online, and it seemed like I was building the module in the right
> way. I also downloaded the latest development version, and that seemed to
> fail in the same way.
>
> Has anyone else had this problem? I'm using flex 2.5.31 and gcc 3.3.1.
>
> Thanks,
> Jeff
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>[/color]

Regards,
Oleg
__________________________________________________ ___________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Tom Lane
Guest
 
Posts: n/a
#3: Nov 11 '05

re: tsearch2 in 7.4beta1 compile problem


Oleg Bartunov <oleg@sai.msu.su> writes:[color=blue]
> On Wed, 13 Aug 2003, Jeff Davis wrote:[color=green]
>> I cd to the tsearch2 directory and typed "make", however I get an error that
>> yy_current_buffer is an undeclared identifier in wordparser/parser.c (which
>> is apparently autogenerated with flex from parser.l).[/color][/color]
[color=blue]
> This is a FAQ. Don't use flex 2.5.31
> Downgrade to stable 2.5.4.[/color]

Still, it would be better if it worked than not. (All the core code
does seem to work with flex 2.5.31 now; only contrib is behind.)

AFAICT tsearch2's incompatibility is in the redefined YY_INPUT macro,
which seems of no value for Postgres anyway. Can't we take that out?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Oleg Bartunov
Guest
 
Posts: n/a
#4: Nov 11 '05

re: tsearch2 in 7.4beta1 compile problem


On Thu, 14 Aug 2003, Tom Lane wrote:
[color=blue]
> Oleg Bartunov <oleg@sai.msu.su> writes:[color=green]
> > On Wed, 13 Aug 2003, Jeff Davis wrote:[color=darkred]
> >> I cd to the tsearch2 directory and typed "make", however I get an error that
> >> yy_current_buffer is an undeclared identifier in wordparser/parser.c (which
> >> is apparently autogenerated with flex from parser.l).[/color][/color]
>[color=green]
> > This is a FAQ. Don't use flex 2.5.31
> > Downgrade to stable 2.5.4.[/color]
>
> Still, it would be better if it worked than not. (All the core code
> does seem to work with flex 2.5.31 now; only contrib is behind.)[/color]

ok. I recall discussion several months ago about 2.5.31 version.
So, we oficially support it ?
[color=blue]
>
> AFAICT tsearch2's incompatibility is in the redefined YY_INPUT macro,
> which seems of no value for Postgres anyway. Can't we take that out?
>[/color]

We'll see.
[color=blue]
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>[/color]

Regards,
Oleg
__________________________________________________ ___________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Tom Lane
Guest
 
Posts: n/a
#5: Nov 11 '05

re: tsearch2 in 7.4beta1 compile problem


Oleg Bartunov <oleg@sai.msu.su> writes:[color=blue]
> On Thu, 14 Aug 2003, Tom Lane wrote:[color=green]
>> Still, it would be better if it worked than not. (All the core code
>> does seem to work with flex 2.5.31 now; only contrib is behind.)[/color][/color]
[color=blue]
> ok. I recall discussion several months ago about 2.5.31 version.
> So, we oficially support it ?[/color]

I wouldn't say that, exactly --- if anyone has any problems with 2.5.31
I'll be the first to say "use 2.5.4". (2.5.31 doesn't even compile on
my primary machine.) But I assume the flex guys will fix their little
problems soon, and that before PG 7.4 reaches end of life the newer flex
behavior will be standard. So I think it behooves us to update our code
to be compatible. The core code all works with either 2.5.4 or 2.5.31
now, and I'd like to see contrib doing the same. (cube and seg are
broken, but I'll work on fixing those if you'll take care of tsearch
and tsearch2.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Teodor Sigaev
Guest
 
Posts: n/a
#6: Nov 11 '05

re: tsearch2 in 7.4beta1 compile problem


[color=blue]
> AFAICT tsearch2's incompatibility is in the redefined YY_INPUT macro,
> which seems of no value for Postgres anyway. Can't we take that out?
>[/color]

Ok, I've removed it from tsearch and tsearch2. But I can't check it with new flex:
% /usr/local/bin/flex -8 -Ptsearch2_yy -o'parser.c' parser.l
m4: illegal option -- P
usage: m4 [-d flags] [-t name] [-gs] [-D name[=value]]...
[-U name]... [-I dirname]... file...

%uname -a
FreeBSD xor 5.1-RELEASE FreeBSD 5.1-RELEASE #3: Fri Jun 13 20:34:53 MSD 2003

So flex calls m4 which isn't gnu m4, it is system utility. GNU m4 is named as
gm4... I can't find any option about which m4 to use.


--
Teodor Sigaev E-mail: teodor@sigaev.ru


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Tom Lane
Guest
 
Posts: n/a
#7: Nov 11 '05

re: tsearch2 in 7.4beta1 compile problem


Teodor Sigaev <teodor@sigaev.ru> writes:[color=blue][color=green]
>> AFAICT tsearch2's incompatibility is in the redefined YY_INPUT macro,
>> which seems of no value for Postgres anyway. Can't we take that out?[/color][/color]
[color=blue]
> I resolve problem with gm4 with a help of symlink and reorder my PATH. So, it
> compiles but creates core dump while regression (postgres is compiled with
> enable-debug and enable-cassert):[/color]

I found the cause -- you had #defined malloc as palloc, etc. That
caused the yy_buffer_stack to get deallocated between calls to the
lexer, which flex isn't expecting. Since you have code to clean up
the lexer state, I don't see any need to use palloc here.

regards, tom lane

---------------------------(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

Closed Thread


Similar PostgreSQL Database bytes