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

On Sun, 1 Oct 2006, Jeremy Drake wrote:

On Sun, 1 Oct 2006, Magnus Hagander wrote:

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.

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.

If you need any specifics, feel free to ping me for it pending that
readme file.

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.

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.

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 think I found a good openssl install for windows, so hopefully that will
work for me. (http://www.slproweb.com/products/Win32OpenSSL.html)

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.

Thanks!

//Magnus

--
Go 'way! You're bothering me!

Jeremy Drake <pgsql@jdrake.com> 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

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

On Mon, 2 Oct 2006, Tom Lane wrote:

Jeremy Drake <pgsql@jdrake.com> 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 ------
1>Compiling...
1>bootparse.c
1>bootparse.tab.c(1065) : error C2449: found '{' at file scope (missing function header?)
1>bootparse.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.

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"

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

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

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

On Mon, 2 Oct 2006, Hiroshi Saito wrote:

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?

I have the platform sdk directories in the dialogs cited, at least I think
in the dialogs cited, since I can't read them ;) And they work ok in the
gui, just not from the command prompt.

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

--
If a jury in a criminal trial stays out for more than twenty-four
hours, it is certain to vote acquittal, save in those instances where
it votes guilty.
-- Joseph C. Goulden

Jeremy Drake <pgsql@jdrake.com> writes:

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!

Certainly not --- we work with both of those (I have 1.875 on one of my
devel machines and 2.1 on two others). In fact, your diff says you have
2.1 on the failing machine and 2.2 on the working one, which got my
attention because I didn't know there was a 2.2.

Right at the moment I'm not seeing what's significant in your diff and
what's just incidental to 2.1-vs-2.2 coding changes and Windows-vs-Linux
\n vs \r\n newline discrepancies. I'm about outta steam for tonight...
anyone else want to look closely?

regards, tom lane

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!

Certainly not --- we work with both of those (I have 1.875 on one
of my devel machines and 2.1 on two others). In fact, your diff
says you have
2.1 on the failing machine and 2.2 on the working one, which got my
attention because I didn't know there was a 2.2.

Right at the moment I'm not seeing what's significant in your diff
and what's just incidental to 2.1-vs-2.2 coding changes and
Windows-vs-Linux \n vs \r\n newline discrepancies. I'm about outta
steam for tonight...
anyone else want to look closely?

Well, it *does* break with 2.1 on win32-native. Could be something
simple, could be that it's just generating msvc-incompatible code. I
didn't look into the details, I tried the older version and then it
worked :-) Never realliy had the time to look into the details of why it
was failing.

//Magnus

"Magnus Hagander" <mha@sollentuna.net> 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

Jeremy Drake <pgsql@jdrake.com> writes:

The errors I got on this file were:
1>bootparse.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 <eggert@cs.ucla.edu>

* 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

On Mon, 2 Oct 2006, Tom Lane wrote:

Jeremy Drake <pgsql@jdrake.com> writes:

The errors I got on this file were:
1>bootparse.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 <eggert@cs.ucla.edu>

* 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.

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: math@sai.msu.ru

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
1>Not re-generating AUTOINC.DEF, file already exists.
1>Linking...
1> Creating library Release\autoinc\autoinc.lib and object Release\autoinc\autoinc.exp
1>autoinc.obj : error LNK2019: unresolved external symbol _SPI_modifytuple referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _pfree referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _pg_detoast_datum referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _nextval referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _DirectFunctionCall1 referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _textin referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _SPI_getbinval referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _SPI_gettypeid referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _errfinish referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol ___msvc_errcode referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _errmsg referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _errstart referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _SPI_fnumber referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _MemoryContextAlloc referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _SPI_getrelname referenced in function _autoinc
1>autoinc.obj : error LNK2019: unresolved external symbol _elog_finish referenced in function _autoinc
1>autoinc.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.

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

Jeremy Drake <pgsql@jdrake.com> writes:

The errors I got on this file were:
1>bootparse.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 <eggert@cs.ucla.edu>

* 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

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.

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

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 ...

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

On Tue, 3 Oct 2006, Magnus Hagander wrote:

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

Here's another interesting tidbit for you: if I run the gendef.pl script
by hand from the visual studio command prompt thing (the one I can't
compile from), it works fine.

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.

ActiveState 5.8.6 build 811 here...

--
If you sit down at a poker game and don't see a sucker, get up. You're
the sucker.

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

Here's another interesting tidbit for you: if I run the
gendef.pl script by hand from the visual studio command
prompt thing (the one I can't compile from), it works fine.

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)

//Magnus

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.

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 "... 2>&1 > file" IIRC, the /out:FILE seems to be
the cleaner approach however :-)

Joachim

"Magnus Hagander" <mha@sollentuna.net> 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

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: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] 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" <mha@sollentuna.net> 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

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

"Magnus Hagander" <mha@sollentuna.net> 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

Tom Lane wrote:

"Magnus Hagander" <mha@sollentuna.net> 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 bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

"Magnus Hagander" <mha@sollentuna.net> 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

"Magnus Hagander" <mha@sollentuna.net> 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