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

2010/3/8 Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>:
>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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/