Re: Compiling extensions on Windows - Mailing list pgsql-hackers

On 01/12/2014 12:00 AM, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> > We don't set __declspec(dllexport) on extension functions automatically
>> > when building stand-alone on Windows. So it's necessary to explicitly
>> > specify PGDLLEXPORT for each function.
> I'm not sure I believe this.  I don't see any PGDLLEXPORT symbols in any
> of the standard contrib modules; how is it that they work?
> 

We force all symbols to be exported using the project file generation
tools in the Pg build system, so PGDLLEXPORT is not required there.

That doesn't help stand alone builds. We don't have anything like PGXS
for Windows, so the only real option for building and distributing
reliably compatible extensions is your own Visual Studio project.

"Just build in contrib/ in a source tree" is not an acceptable answer,
because extensions need binary compatibility with public installer
distributions like the one EDB maintains. Unless you're sure your build
is set up just the same way I'm not at all convinced you're going to get
that, though you may get something that works *most* of the time. This
hasn't historically been a project keen on "mostly" solutions though.

> So if it's really necessary to change anything here, I'd rather see us
> take the approach of hiding it in PG_FUNCTION_INFO_V1.  What happens
> if we do that and there's also a manually-written prototype?

I've run out of weekend and have to go full-speed on upd. sb. views,
BDR, and event triggers tomorrow, so I don't think I'll have a chance to
test it immediately. I'll check after the CF deadline. That's certainly
one option, anyway, and one that'll solve the immediate issue with
extensions, and would be the most practical short term solution if it works.

Otherwise we can just add DLLEXPORT macros on public functions in
contrib/ and the docs. They're harmless on other platforms - and in fact
can be quite handy.



Those "windows droppings" can actually be useful: They annotate sources
with a useful piece of information we don't currently use on *nix, but
probably should. They specify a shared library or executable's public
interface.

Imagine that the macro was called "PGAPI" or "PG_PUBLIC_API", not
"PGDLLEXPORT". That's what it actually *means*, really.

On *nix we treat the executable and shared lib APIs as the union of the
exported symbols of all compilation units in the object. That's rather
crude, as it means that something very internal to Pg must be public if
it's to be visible across more than one compilation unit, and that if we
wish to hide it we have to squash things together into bigger
compilation units than we might otherwise want.

That's a pain for backward compat, as theoretically all of PostgreSQL's
exported symbols are public API. We don't really offer a good way to
tell what's public and what's not anyway.

Instead, we can and (IMO) should be marking our public API explicitly.
If it's supposed to be usable from a contrib / extension / fdw / etc,
mark it PGDLLEXPORT. Or rename that PG_PUBLIC_API and label it that.
Whatever. On Windows, these expand to __declspec(dllexport) and cause
symbol export. On gcc, we switch to building with -fvisiblity=hidden and
have these macros expand to __attribute__ ((dllexport)) . Access to
non-exported symbols becomes a link error. On ancient GCCs and on other
toolchains we continue to export all symbols by default, as now.

This'd reduce symbol table sizes a bit - though it's really only a big
win for C++ code with monster symbol tables. More importantly, it'd make
it easier to tell what's supposed to be reasonably stable across
versions as public API, and what's totally internal.

(It might be that we have enough exts delving deep in to Pg's guts
already that this is impractical. It'd be fun to see.)

Related references:
 http://gcc.gnu.org/wiki/Visibility http://people.redhat.com/drepper/dsohowto.pdf

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services