Hi,
This is my first -hackers message; I've recently been putting some effort
into PL/Java since this summer (my employer published a restated IP policy
that seems much friendlier toward FOSS contributions on my own time, so
my PL/Java contributions will be seen to have ticked up since then).
Ken Olson has helped me greatly by testing on Windows, and he noticed
something odd: #include <server/dynloader.h> fails on Windows when building
an extension out-of-tree, simply because that file isn't there. He tells me
that a lot of sites using PG on Windows will have obtained it from an EDB
binary distribution, so I am not sure whether that file is missing because
of PG's Windows build tooling, or because of something in the way EDB makes
their packages.
As far as either of us can tell, the <dynloader.h> file distributed for
any given platform is one of the templates in backend/port/dynloader,
and (on platforms that use configure), the proper one is chosen by
configure, and ends up supplied as dynloader.h in postgresql-devel
sorts of packages, so it can be seen when building extensions out-of-tree.
There is a win32.h in backend/port/dynloader, and Ken got compilation to
succeed by duplicating the contents of that file in place of the #include,
so it seems that is the file that *should* become <dynloader.h> in a
Windows package. I do notice there is a tools/msvc/Mkvcbuild.pm with code
in it to make use of the backend/port/dynloader/win32.c file, but it
makes no mention of the .h file.
Am I right in thinking some version of <server/dynloader.h> is intended
to be present on every platform, and its absence on Windows is simply
an oversight in building/packaging? The compiler seems happy with
#ifndef _MSC_VER
#include <server/dynloader.h>
#else
... pasted copy of win32.h from the source tree ...
#endif
but I assume it's preferable to have the same code work on Windows as on
other platforms when possible.
Regards,
Chapman Flack