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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
