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
getsdefined 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
bunchof 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
Sheykhetposted at http://www.postgresql.org/docs/8.2/interactive/xfunc-c.html with the same problem (now that I know
howto 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
includeor 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@postnewspapers.com.au]
Sent: 05 March 2010 10:05
To: Kevin Flanagan
Cc: pgsql-hackers@postgresql.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
isdownloaded 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
theresome 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