Re: [HACKERS] src/tools/msvc usage instructions
On Tue, 3 Oct 2006, Magnus Hagander wrote: Looks like the gendef script is failing. Check the contents of release\postgres\postgres.def - it should have thousands of symbols, but I'm willing to bet it's empty... It contains one word: EXPORTS. I assume this means it is empty. What should I do about it? Is there something I can check to see why this is failing? //Magnus -- Honesty is the best policy, but insanity is a better defense. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] src/tools/msvc usage instructions
Looks like the gendef script is failing. Check the contents of release\postgres\postgres.def - it should have thousands of symbols, but I'm willing to bet it's empty... It contains one word: EXPORTS. I assume this means it is empty. What should I do about it? Is there something I can check to see why this is failing? Yup. Delete the DEF file and run the gendef command manually (see the project file for commandline, IIRC there are no parameters, but just to be sure). I'm wondering if you're seeing the samre problem as Joachim Wieland (off-list conversation) where the output from dumpbin.exe goes to the console instead of the pipe in the perl program... //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
On Tue, 3 Oct 2006, Magnus Hagander wrote: Looks like the gendef script is failing. Check the contents of release\postgres\postgres.def - it should have thousands of symbols, but I'm willing to bet it's empty... It contains one word: EXPORTS. I assume this means it is empty. What should I do about it? Is there something I can check to see why this is failing? Yup. Delete the DEF file and run the gendef command manually (see the project file for commandline, IIRC there are no parameters, but just to be sure). I'm wondering if you're seeing the samre problem as Joachim Wieland (off-list conversation) where the output from dumpbin.exe goes to the console instead of the pipe in the perl program... I was just checking this, I read the gendef script, and saw it would short-circut if postgres.def existed, so I deleted the file and ran a build in visual studio again and it printed all kinds of dumpbin output into the visual stuio output window, which I remember it did before. Since you have seen this before, what was the fix (or was there one)? -- It's raisins that make Post Raisin Bran so raisiny ... ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
Delete the DEF file and run the gendef command manually (see the project file for commandline, IIRC there are no parameters, but just to be sure). I'm wondering if you're seeing the samre problem as Joachim Wieland (off-list conversation) where the output from dumpbin.exe goes to the console instead of the pipe in the perl program... I was just checking this, I read the gendef script, and saw it would short-circut if postgres.def existed, so I deleted the file and ran a build in visual studio again and it printed all kinds of dumpbin output into the visual stuio output window, which I remember it did before. Since you have seen this before, what was the fix (or was there one)? No fix yet :-( Haven't had the time to dig into it properly, but I think we can now safely say it's not a local issue in Joachims build env :-) If you just run a dumpbin command (the same way) manually with a foo, does it redirect it properly then? Or is dumpbin for some reason not writing on stdout? It runs perfectly on two completely separate build envs I have here :-O Could someone who knows perl a bit more than me take a look at that script (src/tools/msvc/gendef.pl) and see if I'm doing something really stupid there? May be that I'm homesick when looking at the code and can't spot obvious things... Also, could it possibly be perl version dependent? I'm on ActiveState 5.8.7 build 815. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] src/tools/msvc usage instructions
On Tue, 3 Oct 2006, Magnus Hagander wrote:
Funky.
Can you try having it run the dumpbin command into a tempfile, and then
open-and-read that tempfile, to see if that makes a difference?
(Assuming you know enough perl to do that, of course)
Doing it as
system(dumpbin /symbols $_ $tmpfn)
still output to the console.
But, I got it to work with the attached patch to the script. Note the use
of the handy /out:FILE parameter to dumpbin for redirecting the output ;)
Also, I changed the file glob to *.obj from * since I got an error trying
to run dumpbin on BuildLog.htm which is obviously not an object file.
Hopefully this is correct?
--
Q: Why do mountain climbers rope themselves together?
A: To prevent the sensible ones from going home.Index: gendef.pl
===
RCS file: X:\\postgres\\cvsuproot/pgsql/src/tools/msvc/gendef.pl,v
retrieving revision 1.1
diff -c -r1.1 gendef.pl
*** gendef.pl 4 Sep 2006 21:30:40 - 1.1
--- gendef.pl 3 Oct 2006 07:20:26 -
***
*** 10,18
print Generating $defname.DEF from directory $ARGV[0]\n;
! while ($ARGV[0]/*) {
print .;
! open(F,dumpbin /symbols $_|) || die Could not open $_\n;
while (F) {
s/\(\)//g;
next unless /^\d/;
--- 10,23
print Generating $defname.DEF from directory $ARGV[0]\n;
! while ($ARGV[0]/*.obj) {
print .;
! #open(F,dumpbin /symbols $_|) || die Could not open $_\n;
! s/\//\\/g;
! system(dumpbin /symbols $_ /out:$_.syms) == 0 or die Could not
dumpbin $_\n;
! my $tmpfn = $_.syms;
! open(F, $tmpfn) || die Could not open $tmpfn\n;
!
while (F) {
s/\(\)//g;
next unless /^\d/;
***
*** 31,36
--- 36,42
push @def, $pieces[6];
}
close(F);
+ unlink $tmpfn;
}
print \n;
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
On Tue, Oct 03, 2006 at 12:27:47AM -0700, Jeremy Drake wrote: On Tue, 3 Oct 2006, Magnus Hagander wrote: Funky. Can you try having it run the dumpbin command into a tempfile, and then open-and-read that tempfile, to see if that makes a difference? (Assuming you know enough perl to do that, of course) Doing it as system(dumpbin /symbols $_ $tmpfn) still output to the console. I could redirect it with ... 21 file IIRC, the /out:FILE seems to be the cleaner approach however :-) Joachim ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] src/tools/msvc usage instructions
Magnus Hagander [EMAIL PROTECTED] writes: which looks like they figured out that they needed to check for MicroSoft C explicitly. I have no idea why they do not define __STDC__ however. Can we just define __STDC__ when compiling that file (or rather, when compiling any bison-generated output file)? Or is that likely to cause *other* issues? That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. We have precedent for adding yes-we'd-like-a-standard-compiler-please switches where necessary, for instance adding -Ae to CFLAGS for HP's compiler. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] src/tools/msvc usage instructions
From my experience with Visual C++, using /Za isn't a good idea. When you set that, the compiler become very pedantic about following the ANSI speck to the letter, which usually means common posix functions aren't available under their normal names (The ansi spec says if the compiler defines functions beyond what in the spec, it's recommended they start with _ to not conflict with application name space). Compatibility with GCC is reduced when you use /Za. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Tuesday, October 03, 2006 8:51 AM To: Magnus Hagander Cc: Jeremy Drake; PostgreSQL Hackers Subject: Re: [HACKERS] src/tools/msvc usage instructions Magnus Hagander [EMAIL PROTECTED] writes: which looks like they figured out that they needed to check for MicroSoft C explicitly. I have no idea why they do not define __STDC__ however. Can we just define __STDC__ when compiling that file (or rather, when compiling any bison-generated output file)? Or is that likely to cause *other* issues? That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. We have precedent for adding yes-we'd-like-a-standard-compiler-please switches where necessary, for instance adding -Ae to CFLAGS for HP's compiler. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
which looks like they figured out that they needed to check for MicroSoft C explicitly. I have no idea why they do not define __STDC__ however. Can we just define __STDC__ when compiling that file (or rather, when compiling any bison-generated output file)? Or is that likely to cause *other* issues? That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. We have precedent for adding yes-we'd-like-a-standard-compiler-please switches where necessary, for instance adding -Ae to CFLAGS for HP's compiler. Unfortunatly, that breaks things so bad it's not even funny. For a file as simple as src/port/win32error.c I get hundreds of errors - many in the win32 header files. Seems you ar eont allowed to pull in the win32 API headers without that flag - just the basic ANSI ones. So that' sjust not going to fly. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] src/tools/msvc usage instructions
Magnus Hagander [EMAIL PROTECTED] writes: That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. Unfortunatly, that breaks things so bad it's not even funny. Um. Well, then we tell people not to use bison 2.1 with MSVC. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] src/tools/msvc usage instructions
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. Unfortunatly, that breaks things so bad it's not even funny. Um. Well, then we tell people not to use bison 2.1 with MSVC. Or add a configure test to prevent it, and display a proper error message. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] src/tools/msvc usage instructions
That seems pretty risky. Better to use the /Za switch or whatever it was to get the compiler to assert it for itself. Unfortunatly, that breaks things so bad it's not even funny. Um. Well, then we tell people not to use bison 2.1 with MSVC. Or add a configure test to prevent it, and display a proper error message. Yeha, I will do this. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] src/tools/msvc usage instructions
Magnus Hagander [EMAIL PROTECTED] writes: Or add a configure test to prevent it, and display a proper error message. Yeha, I will do this. As long as we're touching that code: the existing test for too-old bison seriously sucks, because all that it does is to print a warning that most people will never notice among all the other spewage from configure. However, erroring out is not better, because for people who're building from a tarball it won't matter what they have. The Right Thing is to print a warning and set up for the missing script to be invoked instead of bison if the files actually need to be built. It looks like all that's needed is to reset YACC to after determining that it's the wrong version, but that should be tested. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] src/tools/msvc usage instructions
Magnus Hagander [EMAIL PROTECTED] writes: Or add a configure test to prevent it, and display a proper error message. Yeha, I will do this. As long as we're touching that code: the existing test for too-old bison seriously sucks, because all that it does is to Oh, I'm not touching configure. This error was for the MSVC build, and it doesn't use configure. I'll be happy to leave the autoconf-fu to others :-) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] src/tools/msvc usage instructions
That's on my TODO list to write, but I haven't had the time yet. The basic is that if you disable everything in the config.pl file, you can run with almost no external dependencies. You'll need flex+bison if buliding off CVS. Oh, and it requires Visual C++ 2005. Should work fine with the Express version. I grabbed flex and bison from GNUwin32 (http://gnuwin32.sourceforge.net/packages/bison.htm) This appears to not work out well. If I copy the generated files from bison from a linux box, then they are ok, but if I try to use ones generated using that version of bison, it does not compile. I'll look around for a different one. That's the onw I'm using. However, be sure to get version 1.875-4, and *not* version 2.1. All right, I started off by commenting out almost all of the options in config.pl, and then ran build.bat from my visual studio 2005 command prompt (the express version). It said that Pthreads is required. Which pthreads implementation is this, and where can I get it? Also, which zlib build for windows is the correct one? There are apparently many different ways to build it. I grabbed the zlib dll from www.zlib.net, and pthreads from ftp://sources.redhat.com/pub/pthreads-win32/ and these seem to compile. Those are the ones. Should work fine to use the binaries as well, no need to compile yourself. I ran into an issue where if I tried to compile using the batch file it would fail with a bunch of errors about not finding windows.h, even when I loaded the environment file from the platform sdk. I had more success opening the solution with the gui, but it is not entirely clear which projects I may need to build in which order. I got the postgres project to compile, so I guess that's a start. If you do build solution it should build all project sin the correct order - there are dependency references set between them that should take care of this automatically. Do you have any idea how to get the environment to know where windows.h is? I even explicitly added the directory to the INCLUDE environment variable, but it did not work. I will try switching to short paths in there in case it is an issue of paths with spaces. In my environment, that gets set when I start the Visual Studio command prompt - that's the whole point abou tusing the VS commandprompt and not a normal one. I think you get a question about integrating the Platform SDK with Visual studio when you install it - any chance you missed that one? I already have ActivePerl and ActivePython installed, so those should work out. I am not really concerned about krb5 and ldap, so as long as commenting them out will disable them, that is good. You can safely leave LDAP in, because it uses only the builtin functionality in the OS and no external dependencies. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] src/tools/msvc usage instructions
On Mon, 2 Oct 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
I grabbed flex and bison from GNUwin32
(http://gnuwin32.sourceforge.net/packages/bison.htm)
This appears to not work out well. If I copy the generated files from
bison from a linux box, then they are ok, but if I try to use ones
generated using that version of bison, it does not compile.
Hm, have you tried diff'ing the output files from the two cases? This
is really probably a question for the flex and bison maintainers, not
us, but it seems like it should work for moderately up-to-date versions
of those tools. What compile failures do you get exactly?
I was just going to chalk it up to a bad matching of tool ports or
something and try to find a different bison, but if you are really
interested...
I get errors on any bison generated file. For simplicity of the diff, I
did not use the first failure I got, which was gram.c, but instead used
the much smaller bootparse.c file. I grabbed the bootparse.c files
generated on windows and on linux, did a diff -cw between them, and tarred
up the three files, which you can get from
http://www.jdrake.com/postgresql/bison-files-win32.tar.gz
The errors I got on this file were:
1-- Build started: Project: postgres, Configuration: Release Win32 --
1Compiling...
1bootparse.c
1bootparse.tab.c(1065) : error C2449: found '{' at file scope (missing
function header?)
1bootparse.tab.c(1858) : error C2059: syntax error : '}'
and then a whole lot of random, uninteresting errors of the kind you get
when the compiler is so confused it no longer knows what it is doing.
I am currently trying to build a newer version of bison using mingw and
use it, but I am running into issues with that also.
Oh, I just got the email from Magnus which says do not use v2.1, but
1.875, so I guess that's what I did wrong. Oops!
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
Drive defensively. Buy a tank.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] src/tools/msvc usage instructions
On Mon, 2 Oct 2006, Magnus Hagander wrote: This appears to not work out well. If I copy the generated files from bison from a linux box, then they are ok, but if I try to use ones generated using that version of bison, it does not compile. I'll look around for a different one. That's the onw I'm using. However, be sure to get version 1.875-4, and *not* version 2.1. Oops, that was it. If you do build solution it should build all project sin the correct order - there are dependency references set between them that should take care of this automatically. If I do build solution it tells me Project not selected to build for this solution configuration for all projects, then 55 skipped at the end. Do you have any idea how to get the environment to know where windows.h is? I even explicitly added the directory to the INCLUDE environment variable, but it did not work. I will try switching to short paths in there in case it is an issue of paths with spaces. In my environment, that gets set when I start the Visual Studio command prompt - that's the whole point abou tusing the VS commandprompt and not a normal one. I think you get a question about integrating the Platform SDK with Visual studio when you install it - any chance you missed that one? Well, it works in the gui, so I thought I got that integrated correctly. One of the deals with the visual c express thing is that it does not come with the headers and libraries and that you have to use the platform sdk instead. I already have ActivePerl and ActivePython installed, so those should work out. I am not really concerned about krb5 and ldap, so as long as commenting them out will disable them, that is good. You can safely leave LDAP in, because it uses only the builtin functionality in the OS and no external dependencies. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- I don't know what you mean by `glory,' Alice said Humpty Dumpty smiled contemptuously. Of course you don't -- till I tell you. I meant `there's a nice knock-down argument for you!' But glory doesn't mean `a nice knock-down argument,' Alice objected. When I use a word, Humpty Dumpty said, in a rather scornful tone, it means just what I choose it to mean -- neither more nor less. The question is, said Alice, whether you can make words mean so many different things. The question is, said Humpty Dumpty, which is to be master-- that's all. -- Lewis Carroll, Through the Looking Glass ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] src/tools/msvc usage instructions
On Sun, 1 Oct 2006, Jeremy Drake wrote: On Mon, 2 Oct 2006, Magnus Hagander wrote: If you do build solution it should build all project sin the correct order - there are dependency references set between them that should take care of this automatically. If I do build solution it tells me Project not selected to build for this solution configuration for all projects, then 55 skipped at the end. I clicked around a little, selected the postgres project in the project list, and switched to the release configuration, and now build solution works. Hmm. Do you have any idea how to get the environment to know where windows.h is? I even explicitly added the directory to the INCLUDE environment variable, but it did not work. I will try switching to short paths in there in case it is an issue of paths with spaces. I switched to short paths in the INCLUDE env var, but it seems to just ignore it. I'll have to look around for how to deal with this, but for now perhaps the gui will work ok. Is there anything that needs to happen post-compile that may not get done if I use the gui? -- H. L. Mencken suffers from the hallucination that he is H. L. Mencken -- there is no cure for a disease of that magnitude. -- Maxwell Bodenheim ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] src/tools/msvc usage instructions
If you do build solution it should build all project sin the correct order - there are dependency references set between them that should take care of this automatically. If I do build solution it tells me Project not selected to build for this solution configuration for all projects, then 55 skipped at the end. I clicked around a little, selected the postgres project in the project list, and switched to the release configuration, and now build solution works. Hmm. Very interesting. Never done that for me :-) I need to do some more checking. Let me know if you figure out exactly why this happens... Do you have any idea how to get the environment to know where windows.h is? I even explicitly added the directory to the INCLUDE environment variable, but it did not work. I will try switching to short paths in there in case it is an issue of paths with spaces. I switched to short paths in the INCLUDE env var, but it seems to just ignore it. I'll have to look around for how to deal with this, but for now perhaps the gui will work ok. Is there anything that needs to happen post-compile that may not get done if I use the gui? Nope. build.bat pretty much just calls mkvcbuild.pl (to generate the project files), and then calls msbuild to build all the project files - the exactly same way the GUI does it. (Or it's supposed to be exactly the same way). Nothing more. So GUI building is just fine, just not automated. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] src/tools/msvc usage instructions
Hi. I think that it has forgotten for VS2005-express to add path of SDK by myself. http://www.winpg.jp/~saito/VS2005/VS2005_Include.png http://www.winpg.jp/~saito/VS2005/VS2005_Library.png Do I mistake your meaning? Regards, Hiroshi Saito I switched to short paths in the INCLUDE env var, but it seems to just ignore it. I'll have to look around for how to deal with this, but for now perhaps the gui will work ok. Is there anything that needs to happen post-compile that may not get done if I use the gui? Nope. build.bat pretty much just calls mkvcbuild.pl (to generate the project files), and then calls msbuild to build all the project files - the exactly same way the GUI does it. (Or it's supposed to be exactly the same way). Nothing more. So GUI building is just fine, just not automated. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] src/tools/msvc usage instructions
Magnus Hagander [EMAIL PROTECTED] writes: Certainly not --- we work with both of those (I have 1.875 on one of my devel machines and 2.1 on two others). Well, it *does* break with 2.1 on win32-native. Could be something simple, could be that it's just generating msvc-incompatible code. Hm, how does it break exactly? There may not be much we can do about it except inform the bison guys, but seems like we should look into it. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
Jeremy Drake [EMAIL PROTECTED] writes:
The errors I got on this file were:
1bootparse.tab.c(1065) : error C2449: found '{' at file scope (missing
function header?)
I looked at this. Line 1065 is the left brace starting yyparse(). On
my Fedora Core 5 box with Bison 2.1 installed, the stuff leading up to
it is
#ifdef YYPARSE_PARAM
... some uninteresting stuff, since we don't define YYPARSE_PARAM ...
#else /* ! YYPARSE_PARAM */
#if defined (__STDC__) || defined (__cplusplus)
int
yyparse (void)
#else
int
yyparse ()
#endif
#endif
{
But lookee here, your Windows-built version has
#ifdef YYPARSE_PARAM
...
#else /* ! YYPARSE_PARAM */
#if defined (__STDC__) || defined (__cplusplus)
int
yyparse (void)
#else
int
yyparse ()
;
#endif
#endif
{
So that semicolon is the source of the trouble. That's clearly a bison
bug, and in fact digging in Red Hat's SRPM shows that they are carrying
a patch for it:
2005-10-05 Paul Eggert [EMAIL PROTECTED]
* data/m4sugar/m4sugar.m4 (_m4_map): New macro.
(m4_map, m4_map_sep): Use it. Handle the empty list correctly.
--- bison-2.1/data/m4sugar/m4sugar.m4
+++ bison-2.1/data/m4sugar/m4sugar.m4
@@ -398,8 +398,11 @@ m4_define([m4_cdr],
# of LIST (which can be lists themselves, for multiple arguments MACROs).
m4_define([m4_fst], [$1])
m4_define([m4_map],
+[m4_if([$2], [[]], [],
+ [_m4_map([$1], [$2])])])
+m4_define([_m4_map],
[m4_ifval([$2],
- [$1(m4_fst($2))[]m4_map([$1], m4_cdr($2))])])
+ [$1(m4_fst($2))[]_m4_map([$1], m4_cdr($2))])])
# m4_map_sep(MACRO, SEPARATOR, LIST)
@@ -408,8 +411,8 @@ m4_define([m4_map],
# are the elements of LIST (which can be lists themselves, for multiple
# arguments MACROs).
m4_define([m4_map_sep],
-[m4_ifval([$3],
- [$1(m4_fst($3))[]m4_map([$2[]$1], m4_cdr($3))])])
+[m4_if([$3], [[]], [],
+ [$1(m4_fst($3))[]_m4_map([$2[]$1], m4_cdr($3))])])
## ##
Presumably bison 2.2 includes this fix. But I guess the real question
is why the devil doesn't MSVC define __STDC__ ? Are they that far
removed from spec compliance?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] src/tools/msvc usage instructions
On Mon, 2 Oct 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
The errors I got on this file were:
1bootparse.tab.c(1065) : error C2449: found '{' at file scope (missing
function header?)
I looked at this. Line 1065 is the left brace starting yyparse(). On
my Fedora Core 5 box with Bison 2.1 installed, the stuff leading up to
it is
#ifdef YYPARSE_PARAM
... some uninteresting stuff, since we don't define YYPARSE_PARAM ...
#else /* ! YYPARSE_PARAM */
#if defined (__STDC__) || defined (__cplusplus)
int
yyparse (void)
#else
int
yyparse ()
#endif
#endif
{
But lookee here, your Windows-built version has
#ifdef YYPARSE_PARAM
...
#else /* ! YYPARSE_PARAM */
#if defined (__STDC__) || defined (__cplusplus)
int
yyparse (void)
#else
int
yyparse ()
;
#endif
#endif
{
So that semicolon is the source of the trouble. That's clearly a bison
bug, and in fact digging in Red Hat's SRPM shows that they are carrying
a patch for it:
2005-10-05 Paul Eggert [EMAIL PROTECTED]
* data/m4sugar/m4sugar.m4 (_m4_map): New macro.
(m4_map, m4_map_sep): Use it. Handle the empty list correctly.
snip patch
Presumably bison 2.2 includes this fix. But I guess the real question
is why the devil doesn't MSVC define __STDC__ ? Are they that far
removed from spec compliance?
In the bison 2.2 generated code, the #if check is
#if (defined __STDC__ || defined __C99__FUNC__ \
|| defined __cplusplus || defined _MSC_VER)
which looks like they figured out that they needed to check for MicroSoft
C explicitly. I have no idea why they do not define __STDC__ however.
regards, tom lane
--
A person is just about as big as the things that make him angry.
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] src/tools/msvc usage instructions
On Mon, 2 Oct 2006, Jeremy Drake wrote: In the bison 2.2 generated code, the #if check is #if (defined __STDC__ || defined __C99__FUNC__ \ || defined __cplusplus || defined _MSC_VER) which looks like they figured out that they needed to check for MicroSoft C explicitly. I have no idea why they do not define __STDC__ however. From msdn ( http://msdn2.microsoft.com/en-us/library/b0084kay.aspx ): __STDC__ Indicates full conformance with the ANSI C standard. Defined as the integer constant 1 only if the /Za compiler option is given and you are not compiling C++ code; otherwise is undefined. Regards, Sergey *** Sergey E. Koposov Max Planck Institute for Astronomy/Sternberg Astronomical Institute Tel: +49-6221-528-349 Web: http://lnfm1.sai.msu.ru/~math E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] src/tools/msvc usage instructions
I now get things to compile, but now I get linker errors on any dll which needs to access symbols from postgres.exe via postgres.lib. For example: 1-- Build started: Project: autoinc, Configuration: Release Win32 -- 1Generate DEF file 1Not re-generating AUTOINC.DEF, file already exists. 1Linking... 1 Creating library Release\autoinc\autoinc.lib and object Release\autoinc\autoinc.exp 1autoinc.obj : error LNK2019: unresolved external symbol _SPI_modifytuple referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _pfree referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _pg_detoast_datum referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _nextval referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _DirectFunctionCall1 referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _textin referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _SPI_getbinval referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _SPI_gettypeid referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _errfinish referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol ___msvc_errcode referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _errmsg referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _errstart referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _SPI_fnumber referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _MemoryContextAlloc referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _SPI_getrelname referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _elog_finish referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _elog_start referenced in function _autoinc 1.\Release\autoinc\autoinc.dll : fatal error LNK1120: 17 unresolved externals I checked the project properties for linker options and it does list Release\postgres\postgres.lib in the additional dependencies list. Any ideas? Am I missing something? -- A penny saved is ridiculous. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
Looks like the gendef script is failing. Check the contents of release\postgres\postgres.def - it should have thousands of symbols, but I'm willing to bet it's empty... //Magnus -Original Message- From: Jeremy Drake [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 1:28 AM To: Magnus Hagander Cc: PostgreSQL Hackers Subject: Re: [HACKERS] src/tools/msvc usage instructions I now get things to compile, but now I get linker errors on any dll which needs to access symbols from postgres.exe via postgres.lib. For example: 1-- Build started: Project: autoinc, Configuration: Release Win32 1-- Generate DEF file Not re-generating AUTOINC.DEF, file already 1exists. 1Linking... 1 Creating library Release\autoinc\autoinc.lib and object 1Release\autoinc\autoinc.exp autoinc.obj : error LNK2019: unresolved 1external symbol _SPI_modifytuple referenced in function _autoinc 1autoinc.obj : error LNK2019: unresolved external symbol _pfree 1referenced in function _autoinc autoinc.obj : error LNK2019: 1unresolved external symbol _pg_detoast_datum referenced in function 1_autoinc autoinc.obj : error LNK2019: unresolved external symbol 1_nextval referenced in function _autoinc autoinc.obj : error LNK2019: 1unresolved external symbol _DirectFunctionCall1 referenced in function 1_autoinc autoinc.obj : error LNK2019: unresolved external symbol 1_textin referenced in function _autoinc autoinc.obj : error LNK2019: 1unresolved external symbol _SPI_getbinval referenced in function 1_autoinc autoinc.obj : error LNK2019: unresolved external symbol 1_SPI_gettypeid referenced in function _autoinc autoinc.obj : error 1LNK2019: unresolved external symbol _errfinish referenced in function 1_autoinc autoinc.obj : error LNK2019: unresolved external symbol 1___msvc_errcode referenced in function _autoinc autoinc.obj : error 1LNK2019: unresolved external symbol _errmsg referenced in function 1_autoinc autoinc.obj : error LNK2019: unresolved external symbol 1_errstart referenced in function _autoinc autoinc.obj : error LNK2019: 1unresolved external symbol _SPI_fnumber referenced in function 1_autoinc autoinc.obj : error LNK2019: unresolved external symbol 1_MemoryContextAlloc referenced in function _autoinc autoinc.obj : 1error LNK2019: unresolved external symbol _SPI_getrelname referenced 1in function _autoinc autoinc.obj : error LNK2019: unresolved external 1symbol _elog_finish referenced in function _autoinc autoinc.obj : 1error LNK2019: unresolved external symbol _elog_start referenced in 1function _autoinc .\Release\autoinc\autoinc.dll : fatal error LNK1120: 117 unresolved externals I checked the project properties for linker options and it does list Release\postgres\postgres.lib in the additional dependencies list. Any ideas? Am I missing something? -- A penny saved is ridiculous. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] src/tools/msvc usage instructions
Jeremy Drake [EMAIL PROTECTED] writes:
The errors I got on this file were:
1bootparse.tab.c(1065) : error C2449: found '{' at file scope
1(missing function header?)
I looked at this. Line 1065 is the left brace starting
yyparse(). On
my Fedora Core 5 box with Bison 2.1 installed, the stuff
leading up to
it is
#ifdef YYPARSE_PARAM
... some uninteresting stuff, since we don't define
YYPARSE_PARAM ...
#else /* ! YYPARSE_PARAM */
#if defined (__STDC__) || defined (__cplusplus) int yyparse (void)
#else int yyparse ()
#endif
#endif
{
But lookee here, your Windows-built version has
#ifdef YYPARSE_PARAM
...
#else /* ! YYPARSE_PARAM */
#if defined (__STDC__) || defined (__cplusplus) int yyparse (void)
#else int yyparse ()
;
#endif
#endif
{
So that semicolon is the source of the trouble. That's clearly a
bison bug, and in fact digging in Red Hat's SRPM shows that
they are
carrying a patch for it:
2005-10-05 Paul Eggert [EMAIL PROTECTED]
* data/m4sugar/m4sugar.m4 (_m4_map): New macro.
(m4_map, m4_map_sep): Use it. Handle the empty list correctly.
snip patch
Presumably bison 2.2 includes this fix. But I guess the
real question
is why the devil doesn't MSVC define __STDC__ ? Are they that far
removed from spec compliance?
In the bison 2.2 generated code, the #if check is
#if (defined __STDC__ || defined __C99__FUNC__ \
|| defined __cplusplus || defined _MSC_VER)
which looks like they figured out that they needed to check
for MicroSoft C explicitly. I have no idea why they do not
define __STDC__ however.
Can we just define __STDC__ when compiling that file (or rather, when
compiling any bison-generated output file)? Or is that likely to cause
*other* issues?
//Magnus
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[HACKERS] src/tools/msvc usage instructions
I was just trying to build using the src/tools/msvc scripts on windows, and I was wondering if there were any instructions on how to do this, what prerequisites there are, where to get them, etc. I couldn't find any, but I may not know the correct place to look. Sorry if this is the wrong list for this question. -- People need good lies. There are too many bad ones. -- Bokonon, Cat's Cradle by Kurt Vonnegut, Jr. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] src/tools/msvc usage instructions
I was just trying to build using the src/tools/msvc scripts on windows, and I was wondering if there were any instructions on how to do this, what prerequisites there are, where to get them, etc. I couldn't find any, but I may not know the correct place to look. That's on my TODO list to write, but I haven't had the time yet. The basic is that if you disable everything in the config.pl file, you can run with almost no external dependencies. You'll need flex+bison if buliding off CVS. Oh, and it requires Visual C++ 2005. Should work fine with the Express version. If you need any specifics, feel free to ping me for it pending that readme file. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] src/tools/msvc usage instructions
Jeremy Drake [EMAIL PROTECTED] writes: I grabbed flex and bison from GNUwin32 (http://gnuwin32.sourceforge.net/packages/bison.htm) This appears to not work out well. If I copy the generated files from bison from a linux box, then they are ok, but if I try to use ones generated using that version of bison, it does not compile. Hm, have you tried diff'ing the output files from the two cases? This is really probably a question for the flex and bison maintainers, not us, but it seems like it should work for moderately up-to-date versions of those tools. What compile failures do you get exactly? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
