Visual Studio 2005, C-language function - avoiding hacks?
in [PgSql]
|
Prev: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?
Next: SQL compatibility reminder: MySQL vs PostgreSQL
From: "Kevin Flanagan" on 5 Mar 2010 17:29 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(a)postnewspapers.com.au] Sent: 05 March 2010 10:05 To: Kevin Flanagan Cc: pgsql-hackers(a)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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Takahiro Itagaki on 8 Mar 2010 01:05 "Kevin Flanagan" <kevin-f(a)linkprior.com> wrote: > 1. you have to define the symbol BUILDING_DLL in your code before > including postgres.h No, BUILDING_DLL does not work. We use PGDLLIMPORT both exported global variables and PG_MODULE_MAGIC/PG_FUNCTION_INFO_V1 for now, but actually we should always use __declspec (dllexport) for the latter cases. They are exported from *user dlls*, not the postgres' one. I'd like to propose to define PGALWAYSEXPORT macro: #ifdef WIN32 #define PGALWAYSEXPORT __declspec (dllexport) #endif and modify PG_MODULE_MAGIC and PG_FUNCTION_INFO_V1 to use it instead of PGDLLEXPORT. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 8 Mar 2010 01:15 Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: > I'd like to propose to define PGALWAYSEXPORT macro: > #ifdef WIN32 > #define PGALWAYSEXPORT __declspec (dllexport) > #endif > and modify PG_MODULE_MAGIC and PG_FUNCTION_INFO_V1 to use it > instead of PGDLLEXPORT. This seems like change for the sake of change. The existing mechanism works (as demonstrated by the fact that the contrib modules work on Windows). I don't think we should invent a new mechanism that won't be backwards-compatible. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Takahiro Itagaki on 8 Mar 2010 01:31 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: > > I'd like to propose to define PGALWAYSEXPORT macro: > > #ifdef WIN32 > > #define PGALWAYSEXPORT __declspec (dllexport) > > #endif > > and modify PG_MODULE_MAGIC and PG_FUNCTION_INFO_V1 to use it > > instead of PGDLLEXPORT. > > This seems like change for the sake of change. The existing mechanism > works (as demonstrated by the fact that the contrib modules work on > Windows). I wonder why the contrib modules can be compiled correctly because: 1. PG_MODULE_MAGIC requires dllexport. 2. Other exported variables from postgres requires dllimport. 3. Exported functions from the contrib DLLs require dllexport, but they don't have any PGDLLEXPORT tags in their functions. Did we use non-standard tools except msvc in the build frameword for core code? And what should I do for an external project? Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 8 Mar 2010 05:08
2010/3/8 Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp>: > > Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >> Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: >> > I'd like to propose to define PGALWAYSEXPORT macro: >> > #ifdef WIN32 >> > #define PGALWAYSEXPORT __declspec (dllexport) >> > #endif >> > and modify PG_MODULE_MAGIC and PG_FUNCTION_INFO_V1 to use it >> > instead of PGDLLEXPORT. >> >> This seems like change for the sake of change. The existing mechanism >> works (as demonstrated by the fact that the contrib modules work on >> Windows). > > I wonder why the contrib modules can be compiled correctly because: > 1. PG_MODULE_MAGIC requires dllexport. > 2. Other exported variables from postgres requires dllimport. > 3. Exported functions from the contrib DLLs require dllexport, > but they don't have any PGDLLEXPORT tags in their functions. > > Did we use non-standard tools except msvc in the build frameword > for core code? And what should I do for an external project? Yes, we use mingw. In this particular case, it may be the non-standard behavior that mingw exports *all* symbols in a DLL. We have some scripts in the MSVC build system that does this - it auto-generates a .DEF file that lists all symbols inthe file, and makes sure those are all exported. In fact, this even requires us to remove warnings created by modern versions of Visual Studio, since you're not supposed to use both dllexport and DEF files for the same symbol, but we do. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |