Re: dynloader.h missing in prebuilt package for Windows? - Mailing list pgsql-hackers

On 11/14/15 18:18, Tom Lane wrote:
> While it may indeed be a packaging bug that that file isn't installed,
> the reason why nobody noticed before is that there doesn't seem to be
> any good reason for anything except dfmgr.c to include it.  What's the
> context?

One of the most long-standing sources of frustration for people newly
trying out PL/Java is its dependence on a libjvm.so, which is usually
found several directories deep under whatever location somebody chose
to install the JRE for the platform in question, and it usually isn't
on the platform's normal dynamic loader search path.

Pretty much *everything else* about PL/Java can be configured via its
custom GUCs, which makes for *almost* a one-stop shop for anything that
has to be configured to make the thing work. To get the pljava.so itself
to load successfully, all you need to do is put it in $libdir, or set
dynamic_library_path to include where it lives, all easy things that any
PGer already finds familiar.

But historically, pljava.so has been built to simply contain a dependency
on libjvm.so, just as it would to any of its other library dependencies.
That's great, but all those other library dependencies are usually on the
OS's dyld search path, and libjvm usually isn't. Because that dependency
is baked into the pljava.so, the OS loader attempts to resolve it
*before* we can have any say in where to look; the search pays no attention
to dynamic_library_path or anything else configured in PG, and when it
fails, there is usually a disorienting error message suggesting that
pljava.so itself was what couldn't be loaded (yes, technically, it couldn't,
but that's not the part of the story that helps anyone).

That one inconvenient fact is the entire reason why PL/Java's install
instructions do not stop after "set these GUCs and you're done", but
instead sprawl on for several more paragraphs of platform-specific ick
about LD_LIBRARY_PATH or linking with DT_RPATH or running ldconfig (which
has systemwide effects!) or whatever other hoops you can jump through on
your platform to make this one library findable.

In the proof-of-concept branch I'm working on (which works great in
Linux already, and Ken is testing on Windows), the build process is
changed so that pljava.so does *not* contain a baked-in dependency on
libjvm. That allows PG to successfully load it, no sweat, and in _PG_init
then it goes out and finds the libjvm *using a pljava.libjvm_location GUC*
and now you do have a one-stop shop where there isn't anything you need
to know to install it besides how to set GUCs. If the GUC is set wrong
and it can't load the library, you get a helpful ereport telling you that's
what went wrong, you change the value, using normal PG mechanisms, and then
it succeeds and you're off to the races.

I know I'm saying it myself, but it makes the initial setup experience
a *lot* less irritating. Ken also thinks it'll greatly simplify
installations some of his users have struggled with.

I use the PG dynloader because, hey, you guys have already done the work
of abstracting up from 12 different platforms' variations on dlopen, and
it seems smarter to stand on your shoulders and not reinvent that. The
one minor quirk is that the declaration of pg_dlsym is tailored to return
a PGFunction specifically, which of course is not the type of the one
function JNI_CreateJavaVM that I need to look up in libjvm. But adding
a cast is no trouble. I am not expecting any platform's wrapped dl*
functions to actually fail if the symbol hasn't got that exact type, right?

Regards,
-Chap