Thread: 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 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 > 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