On 02/13/2014 08:26 AM, Andres Freund wrote:
>> > It gets worse, too. Say you want hstore to export a couple of symbols.
>> > Those symbols must be __declspec(dllexport) while everything else in
>> > headers must be __declspec(dllimport). This means you can't just use
>> > PGDLLIMPORT. You must define a HSTOREDLLIMPORT that's
>> > __declspec(dllexport) when compiling hstore and otherwise
>> > __declspec(dllimport). Then set a preprocessor macro like
>> > -DCOMPILING_HSTORE to trigger it.
> We actually have a a macro that should do that, namely PGDLLEXPORT. I am
> not sure though, why it's not dependent on dependent on BUILDING_DLL
> (which is absolutely horribly misnamed, being essentially inverted).
Yes, it does that *for building postgres*.
What I'm saying is that you need another one for hstore if you wish to
be able to export symbols from hstore and import them into other libs.
You can't use PGDLLEXPORT because BUILDING_DLL will be unset, so it'll
expand to __declspec(dllimport) while compiling hstore. Which is wrong
if you want to be exporting symbols; even if you use a .DEF file, it
must expand blank, and if you don't use a .DEF it must expand to
__declspec(dllexport) ... but ONLY for those symbols exported by hstore
its self.
So each lib that wants to export symbols needs its own equivalent of
PGDLLIMPORT, and a flag set just when compiling that lib.
This is the normal way it's done on Windows builds, not stuff I'm
looking into and saying how _I_ think we should do it. AFAIK this is
just how it's done on Windows, horrible as that is. I'll see if I can
find a couple of relevant links.
BTW, BUILDING_DLL is so-named because the macro definition will be taken
from examples that talk about compiling a DLL, that's all.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
