Bison 2.1 on win32
I just tried building with Bison 2.1 on msvc, and it broke. For one
thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is
obviously incorrect :-)
But the generated C file also does not compile causing the error on
http://msdn2.microsoft.com/en-us/library/93az0868.aspx, because msvc
doesn't define __STDC__, which causes Bison to generate code it can't
compile. Defining __STDC__ globally breaks several other places, since
it affects a lot of include files that aren't necessarily others.
The attached patch seems to fix the build issue. Does it seem
acceptable/the right thing to do?
Another option would be to just reject both 2.0 and 2.1 as broken to
build pg with, I guess...
//Magnus
Attachments:
bison.patchtext/plain; name=bison.patchDownload
Index: src/backend/parser/gram.y
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.581
diff -c -r2.581 gram.y
*** src/backend/parser/gram.y 13 Mar 2007 00:33:41 -0000 2.581
--- src/backend/parser/gram.y 17 Mar 2007 13:14:40 -0000
***************
*** 62,67 ****
--- 62,71 ----
#include "utils/numeric.h"
#include "utils/xml.h"
+ /* MSVC does not define __STDC__, but Bison 2.1 generates broken code without it */
+ #ifdef WIN32_ONLY_COMPILER
+ #define __STDC__ 1
+ #endif
/* Location tracking support --- simpler than bison's default */
#define YYLLOC_DEFAULT(Current, Rhs, N) \
Index: src/backend/bootstrap/bootparse.y
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/bootstrap/bootparse.y,v
retrieving revision 1.88
diff -c -r1.88 bootparse.y
*** src/backend/bootstrap/bootparse.y 13 Mar 2007 00:33:39 -0000 1.88
--- src/backend/bootstrap/bootparse.y 17 Mar 2007 13:14:56 -0000
***************
*** 51,56 ****
--- 51,61 ----
#include "tcop/dest.h"
#include "utils/rel.h"
+ /* MSVC does not define __STDC__, but Bison 2.1 generates broken code without it */
+ #ifdef WIN32_ONLY_COMPILER
+ #define __STDC__ 1
+ #endif
+
#define atooid(x) ((Oid) strtoul((x), NULL, 10))
Index: src/pl/plpgsql/src/gram.y
===================================================================
RCS file: /projects/cvsroot/pgsql/src/pl/plpgsql/src/gram.y,v
retrieving revision 1.99
diff -c -r1.99 gram.y
*** src/pl/plpgsql/src/gram.y 19 Feb 2007 03:18:51 -0000 1.99
--- src/pl/plpgsql/src/gram.y 17 Mar 2007 13:15:11 -0000
***************
*** 18,23 ****
--- 18,27 ----
#include "parser/parser.h"
+ /* MSVC does not define __STDC__, but Bison 2.1 generates broken code without it */
+ #ifdef WIN32_ONLY_COMPILER
+ #define __STDC__ 1
+ #endif
static PLpgSQL_expr *read_sql_construct(int until,
int until2,
Magnus Hagander wrote:
I just tried building with Bison 2.1 on msvc, and it broke. For one
thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is
obviously incorrect :-)But the generated C file also does not compile causing the error on
http://msdn2.microsoft.com/en-us/library/93az0868.aspx, because msvc
doesn't define __STDC__, which causes Bison to generate code it can't
compile. Defining __STDC__ globally breaks several other places, since
it affects a lot of include files that aren't necessarily others.The attached patch seems to fix the build issue. Does it seem
acceptable/the right thing to do?Another option would be to just reject both 2.0 and 2.1 as broken to
build pg with, I guess...
I rolled back to 1.875 to get MSVC builds working. In the longer term,
though, falling behind upstream is probably not a good idea. Should this
be reported to the bison people?
For now I could live with either of your solutions.
cheers
andrew
Magnus Hagander <magnus@hagander.net> writes:
The attached patch seems to fix the build issue. Does it seem
acceptable/the right thing to do?
No, it seems pretty bletcherous.
Another option would be to just reject both 2.0 and 2.1 as broken to
build pg with, I guess...
In bison 2.3 (which is shipping with Fedora Core 6), all the uses of
__STDC__ seem to also test _MSC_VER:
#if (defined __STDC__ || defined __C99__FUNC__ \
|| defined __cplusplus || defined _MSC_VER)
If this fixes the problem, then I'd vote for just stating you need
bison >= 2.3 (or 2.2?) to build on MSVC.
regards, tom lane
Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
The attached patch seems to fix the build issue. Does it seem
acceptable/the right thing to do?No, it seems pretty bletcherous.
That's kind of what I thought :-)
Another option would be to just reject both 2.0 and 2.1 as broken to
build pg with, I guess...In bison 2.3 (which is shipping with Fedora Core 6), all the uses of
__STDC__ seem to also test _MSC_VER:#if (defined __STDC__ || defined __C99__FUNC__ \
|| defined __cplusplus || defined _MSC_VER)If this fixes the problem, then I'd vote for just stating you need
bison >= 2.3 (or 2.2?) to build on MSVC.
It certainly looks like it would fix it. However, the gnuwin32 project
doesn't have 2.3, not even 2.2. But let's add a check and say we need
it, and then we can fix it again once they do release that version if
it's broken still...
Do you happen to have a 2.2 around so you can see what happens there? Or
does someone else have that? So I know which version to test against...
//Magnus
Magnus Hagander wrote:
I just tried building with Bison 2.1 on msvc, and it broke. For one
thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is
obviously incorrect :-)
Actually, looking at the GNU ftp site, there isn't even a version 2.2
available. There is a 2.1a which should have the fix (based on file
dates - they don't use branches or tags in their cvs repository).
But I'll go ahead and just say it's fixed in 2.3, and patch accordingly.
//Magnus
Magnus Hagander <magnus@hagander.net> writes:
Actually, looking at the GNU ftp site, there isn't even a version 2.2
available. There is a 2.1a which should have the fix (based on file
dates - they don't use branches or tags in their cvs repository).
Huh? At
http://ftp.gnu.org/gnu/bison/
I see 2.0, 2.1, 2.2, 2.3, and no 2.1a.
regards, tom lane
Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
Actually, looking at the GNU ftp site, there isn't even a version 2.2
available. There is a 2.1a which should have the fix (based on file
dates - they don't use branches or tags in their cvs repository).Huh? At
http://ftp.gnu.org/gnu/bison/
I see 2.0, 2.1, 2.2, 2.3, and no 2.1a.
Gah. I clicked the wrong link that was titled "test releases" ;-) I just
found a second ftp link when the first one didn't work. Should've read
more carefully.
Ok. So it looks like 2.2 should be fine as well, as soon as they put out
a new win32 ver... (FYI, the code seems to come from data/c.m4)
/Magnus
Magnus Hagander <magnus@hagander.net> writes:
Do you happen to have a 2.2 around so you can see what happens there? Or
does someone else have that? So I know which version to test against...
2.2 and 2.3 seem to use _MSC_VER in the same way. I had occasion to
test both last fall, and they generate only trivially different
outputs from our grammar.
regards, tom lane
Hi.
I was operating in a tentative way by 2.3.
Still, it is not sufficient. However, it moves.
I will think that I am glad, if it can adjust with Magnus.
http://winpg.jp/~saito/MinGW/bison-2.3_win32_src.tgz
Regards,
Hiroshi Saito
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Magnus Hagander" <magnus@hagander.net>
Cc: "PGSQL Hackers" <pgsql-hackers@postgresql.org>
Sent: Sunday, March 18, 2007 2:06 AM
Subject: Re: [HACKERS] Bison 2.1 on win32
Show quoted text
Magnus Hagander <magnus@hagander.net> writes:
Do you happen to have a 2.2 around so you can see what happens there? Or
does someone else have that? So I know which version to test against...2.2 and 2.3 seem to use _MSC_VER in the same way. I had occasion to
test both last fall, and they generate only trivially different
outputs from our grammar.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings