Обсуждение: What bison versions are installed on buildfarm machines?
Is there any way to find out $subject? I see that several of the
buildfarm machines are choking on a patch I committed yesterday:
guc-file.l: In function `ProcessConfigFile':
guc-file.l:162: error: `YY_FLUSH_BUFFER' undeclared (first use in this function)
guc-file.l:162: error: (Each undeclared identifier is reported only once
guc-file.l:162: error: for each function it appears in.)
make[4]: *** [guc.o] Error 1
YY_FLUSH_BUFFER is documented as a standard macro in bison 1.875, which
is the oldest version we officially support. But I'm prepared to change
it if there is another way that would work with a wider range of bison
versions.
regards, tom lane
Tom Lane said: > Is there any way to find out $subject? I see that several of the > buildfarm machines are choking on a patch I committed yesterday: > > guc-file.l: In function `ProcessConfigFile': > guc-file.l:162: error: `YY_FLUSH_BUFFER' undeclared (first use in this > function) guc-file.l:162: error: (Each undeclared identifier is > reported only once guc-file.l:162: error: for each function it appears > in.) > make[4]: *** [guc.o] Error 1 > > YY_FLUSH_BUFFER is documented as a standard macro in bison 1.875, which > is the oldest version we officially support. But I'm prepared to > change it if there is another way that would work with a wider range of > bison versions. > Some months ago we put in a feature that allows you to see the log of all stages, not just the stage that failed. Not all buildfarm members have yet been updated to that release, unfortunately, so you won't see it on every details page. Among those with this failure that have updated is rook. See the stage logs here: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=rook&dt=2006-01-02%2011:39:01 the "config" link is the config.log file configure produces, and the "configure" link is its stdout. configure doesn't actually report the bison version, but it does complain if the version is less than 1.875, and I don't see that on rook. cheers andrew
Tom Lane wrote: > Is there any way to find out $subject? I see that several of the > buildfarm machines are choking on a patch I committed yesterday: > > guc-file.l: In function `ProcessConfigFile': > guc-file.l:162: error: `YY_FLUSH_BUFFER' undeclared (first use in this function) > guc-file.l:162: error: (Each undeclared identifier is reported only once > guc-file.l:162: error: for each function it appears in.) > make[4]: *** [guc.o] Error 1 > > YY_FLUSH_BUFFER is documented as a standard macro in bison 1.875, which > is the oldest version we officially support. But I'm prepared to change > it if there is another way that would work with a wider range of bison > versions. I just verified that -HEAD is broken on Debian Sarge 3.1 (nearly all of the failing buildfarm members are Debian Sarge 3.1 boxes) - and I just verified the Problem exists on i386 too. The version of bison available on Debian Sarge reports as: bison (GNU Bison) 1.875d Written by Robert Corbett and Richard Stallman. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Stefan
"Andrew Dunstan" <andrew@dunslane.net> writes:
> configure doesn't actually report the bison version, but it does complain if
> the version is less than 1.875, and I don't see that on rook.
Sigh, I haven't woken up entirely today :-( ... of course, this is a
flex macro we are talking about, not bison.
Our configure script does complain about flex 2.5.3, and I don't see
that warning in rook's output, but perhaps some even older flex version
is installed there? Hard to believe ... even 2.5.4 is pretty ancient.
regards, tom lane
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> I just verified that -HEAD is broken on Debian Sarge 3.1 (nearly all of
> the failing buildfarm members are Debian Sarge 3.1 boxes) - and I just
> verified the Problem exists on i386 too.
What flex version are they using?
regards, tom lane
Tom Lane wrote: > Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes: > >>I just verified that -HEAD is broken on Debian Sarge 3.1 (nearly all of >>the failing buildfarm members are Debian Sarge 3.1 boxes) - and I just >>verified the Problem exists on i386 too. > > > What flex version are they using? flex 2.5.31 Stefan
Tom Lane wrote: >"Andrew Dunstan" <andrew@dunslane.net> writes: > > >>configure doesn't actually report the bison version, but it does complain if >>the version is less than 1.875, and I don't see that on rook. >> >> > >Sigh, I haven't woken up entirely today :-( ... of course, this is a >flex macro we are talking about, not bison. > >Our configure script does complain about flex 2.5.3, and I don't see >that warning in rook's output, but perhaps some even older flex version >is installed there? Hard to believe ... even 2.5.4 is pretty ancient. > > Not that hard to believe. 2.5.4 is what the major distributions are shipping. Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex is now considered a NON-GNU project. The currently supported Flex is up to 2.5.31. Joshua D. Drake > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 2: Don't 'kill -9' the postmaster > > -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Not that hard to believe. 2.5.4 is what the major distributions are
> shipping.
> Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex
> is now considered a NON-GNU project.
No, the major reason for it is that flex 2.5.31 is seriously broken and
non-compatible with its prior releases. I wasn't aware that they'd gone
so far as to remove a documented macro (one that was documented in 2.5.4
as the *preferred* way to do things, mind you) but we already knew of
several other issues with it. See the archives.
I'll try to snarf a copy and see if there's a way to do it that's
compatible with both releases, but it's the flex authors' own fault
that 2.5.31 has had such poor uptake.
regards, tom lane
Tom, On corgi (debian sarge) raq:~# bison -V bison (GNU Bison) 1.875a ---------- Original Message ----------- From: Tom Lane <tgl@sss.pgh.pa.us> To: pgsql-hackers@postgresql.org Sent: Mon, 02 Jan 2006 12:54:42 -0500 Subject: [HACKERS] What bison versions are installed on buildfarm machines? > Is there any way to find out $subject? I see that several of the > buildfarm machines are choking on a patch I committed yesterday: > > guc-file.l: In function `ProcessConfigFile': > guc-file.l:162: error: `YY_FLUSH_BUFFER' undeclared (first use in this function) > guc-file.l:162: error: (Each undeclared identifier is reported only once > guc-file.l:162: error: for each function it appears in.) > make[4]: *** [guc.o] Error 1 > > YY_FLUSH_BUFFER is documented as a standard macro in bison 1.875, which > is the oldest version we officially support. But I'm prepared to change > it if there is another way that would work with a wider range of bison > versions. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster ------- End of Original Message -------
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > >>Not that hard to believe. 2.5.4 is what the major distributions are >>shipping. >>Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex >>is now considered a NON-GNU project. > > > No, the major reason for it is that flex 2.5.31 is seriously broken and > non-compatible with its prior releases. I wasn't aware that they'd gone > so far as to remove a documented macro (one that was documented in 2.5.4 > as the *preferred* way to do things, mind you) but we already knew of > several other issues with it. See the archives. > > I'll try to snarf a copy and see if there's a way to do it that's > compatible with both releases, but it's the flex authors' own fault > that 2.5.31 has had such poor uptake. hmm it does not seem to work with the 2.5.4 version debian supplies as "flex-old" too - maybe the following debian bug report(filed against woody!) is related to this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=194904 Stefan
Stefan Kaltenbrunner wrote: > Tom Lane wrote: > >>"Joshua D. Drake" <jd@commandprompt.com> writes: >> >> >>>Not that hard to believe. 2.5.4 is what the major distributions are >>>shipping. >>>Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex >>>is now considered a NON-GNU project. >> >> >>No, the major reason for it is that flex 2.5.31 is seriously broken and >>non-compatible with its prior releases. I wasn't aware that they'd gone >>so far as to remove a documented macro (one that was documented in 2.5.4 >>as the *preferred* way to do things, mind you) but we already knew of >>several other issues with it. See the archives. >> >>I'll try to snarf a copy and see if there's a way to do it that's >>compatible with both releases, but it's the flex authors' own fault >>that 2.5.31 has had such poor uptake. > > > hmm it does not seem to work with the 2.5.4 version debian supplies as > "flex-old" too - maybe the following debian bug report(filed against > woody!) is related to this: sorry for the false alarm, actually i can confirm that 2.5.31 (which is the default flex on Sarge) is broken and 2.5.4 (available as flex-old) DOES work. Stefan
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> sorry for the false alarm, actually i can confirm that 2.5.31 (which is
> the default flex on Sarge) is broken and 2.5.4 (available as flex-old)
> DOES work.
Using yyrestart() seems to work with both versions --- fix committed.
regards, tom lane