Re: Visual Studio 2005, C-language function - avoiding hacks?

Ok, that got me on the right track, thanks. I think the key points for this build scenario are these:

1. you have to define the symbol BUILDING_DLL in your code before including postgres.h (as that then means PGDLLIMPORT gets defined right in pg_config_os.h). That makes the 'inconsistent dll linkage' warnings go away.
2. you have to have include\server\port\win32 in the include dirs list as well as include\server (as that provides a bunch of otherwise-missing headers such as netdb.h)

However, that still leaves one missing include file - libintl.h, which c.h tries to include because ENABLE_NLS is defined (and that seems to get defined as 1 in pg_config.h whether you like it or not). And in fact, it seems Rostic Sheykhet posted at http://www.postgresql.org/docs/8.2/interactive/xfunc-c.html with the same problem (now that I know how to do it, I know what to Google for to, er, find out how to do it :) ). You can get round it by commenting out the include or creating a dummy libintl.h.

Just posting the results here in case they're relevant for anything.

Kevin.

-----Original Message-----
From: Craig Ringer [mailto:craig(at)postnewspapers(dot)com(dot)au]
Sent: 05 March 2010 10:05
To: Kevin Flanagan
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?

Kevin Flanagan wrote:
> Ok, re "building with the win32 configuration" ... that sounds like just the thing I should know about. All I've done is downloaded and installed the 1-click installer for Windows from http://www.enterprisedb.com/products/pgdownload.do#windows ... so while I'm sure it knows it's running on Win32, is there some other configuration change I should make for dev purposes to indicate that it's "the win32 configuration"? Or does "building with the win32 configuration" refer to those who are building the server from source, or something?

I wasn't too specific because it's been a while since I did any coding
against Pg on win32, and I couldn't remember exactly how it selected the
right code to use for a given platform - whether it was a macro that
must be defined, or what.

Having had a look at the sources: It's done by header search path. You
need to make sure that include/port/win32_msvc is on the header search
path as well as the main include/ directory.

I *think* port/win32 is for the MinGW win32 port and thus shouldn't be
included in the search path for msvc builds, but I'm not 100% sure of
that and a quick look doesn't reveal any documentation on the matter.

--
Craig Ringer