"Kevin Flanagan" <kevin-f@linkprior.com> writes:
> Aha. I'd read that the build process for the contrib modules involved
> generating a .DEF file for the necessary exports. I had the impression that
> defining BUILDING_DLL was an alternative, addressing (part) of the issue
> (that is, PG_FUNCTION_INFO_V1 declares functions as 'extern PGDLLIMPORT',
> and if you define BUILDING_DLL, then PGDLLIMPORT is defined as ' __declspec
> (dllexport)'). But you're quite right, if I take out the BUILDING_DLL
> definition, and put the __declspec (dllexport) stuff in piecemeal, the
> access violation goes away. Thank goodness.
I remember having complained that that part of the PG_FUNCTION_INFO_V1
macro seemed backwards, and never really getting a satisfactory
explanation of why it isn't (ie, why it shouldn't be designed to expand
as __declspec (dllexport) instead). But anyway, I think the
conventional wisdom for exporting functions from a loadable module is
to use "dlltool --export-all" rather than bothering with being
selective.
regards, tom lane
