Skip site navigation (1) Skip section navigation (2)

Building with Visual C++

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: <pgsql-patches(at)postgresql(dot)org>
Subject: Building with Visual C++
Date: 2006-04-23 20:10:54
Message-ID: (view raw or flat)
Lists: pgsql-patches
I've been working on getting the full backend to compile and run using
Visual C++ instead of mingw/gcc, and have made some good progress.
First, why do this? A couple of reasons:

1) MS VC++ is a significantly faster compiler, so rebuilding is much
faster ;)

2) MS VC++ supposedly has a better optimiser. I haven't got any pg
figures for this, but I've heard it from many other projects.

3) MS VC++ generates debug symbols in a way that's compatible with a
Windows debugger - such as the one in Visual Studio, but also the basic
WinDbg debuggers that are the "standard windows debuggers". gdb is
horrible on win32.

4) It should also work with Visual Studio profiler tools. gprof is also
pretty horrible on win32.

Unlike the previous stuff we do with VC++ this one doesn't use separate
Makefiles. Instead I have a script that generates complete Visual Studio
solution and project files by parsing the existing Makefiles. This build
script isn't completed yet, there are a few too many things hardcoded in
it. But it *works*, and the produced binary passes all regression tests
except one (more on this in a separate mail in a minute or two). With
this it should also build fine with Visual C++ Express (free download
from MS), also not tested yet.

Turns out the changes are pretty small - most of the needed stuff was
implemented in /port already, and just needed activation for win32.

The attached patch makes some changes in the code required to work for
this, and some clenaups. A summary of the changes is:

*) WIN32_CLIENT_ONLY was a very bad name for a macro, since it pretty
much meant "visual c++". In a lot of places, it's just removed (need
removed by changing headers), in the few places where it's relevant we
instead use _MSC_VER which properly indicates Visual C++.

*) Change all open() commands to use the three parameter version. This
is because Visual C++ didn't support variadic macros until version 8 (VS
2005). It's only a very few places that used the two parameter version,
so I think it's fine to make this change for all platforms.

*) Change where NaN is generated. Using 0.0/0.0 doesn't work in VC++
because it detects it as a divide-by-zero at the compile stage. Storing
the second 0.0 in a variable makes this work. I made the change for all
platforms to avoid #ifdef, but if that's not acceptable it can of course
easily be made inside a #ifdef.

*) Cleanup incorrect definitions of several WINAPI functions. They were
simply wrong, but mingw/gcc accepted it anyway..

*) Sync up pg_config.h.win32 to be a mingw-configure-output version with
a couple of minor changes (listed). This is the largest part of the

*) Add s_lock implementation based on InterlockedCompareExchange instead
of assembly code (gcc style asm not supported, and this should probably
be about as fast from what I hear)

*) It also updates the old Visual C++ makefiles to still work. I expect
them to go away once I'm done with the buildscript, but for now they
needed some small updates.

Finally, a couple of files are added to the tree:

src/include/port/win32vc/* - stub include files the same way
src/include/port/win32 is used already.

src/port/dirent.c - opendir/readdir/closedir implementation for win32,
that doesn't even have the bugs mingw had in it ;)

Hmm. That mail turned out longer than intended. Let's hope that means I
didn't forget anything...


Attachment: vcbuild.patch
Description: application/octet-stream (63.7 KB)
Attachment: vcbuild_newfiles.tar.gz
Description: application/x-gzip (1.5 KB)


pgsql-patches by date

Next:From: Martijn van OosterhoutDate: 2006-04-23 21:55:03
Subject: [PATCH] 4 coverity patches for ECPG
Previous:From: Bruce MomjianDate: 2006-04-23 18:30:51
Subject: Re: Additional current timestamp values

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group