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 1YY_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 1YY_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 1YY_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