References: <56F170BA.2000202@goldencode.com> <56F1FC23.1010904@anastigmatix.net> <56F2D1C0.6060801@goldencode.com> <56F6FB2B.9050209@anastigmatix.net> <56F70A73.3000209@goldencode.com> From: Chapman Flack Message-ID: <56F70E02.3070805@anastigmatix.net> Date: Sat, 26 Mar 2016 18:32:34 -0400 MIME-Version: 1.0 In-Reply-To: <56F70A73.3000209@goldencode.com> Subject: Re: [Pljava-dev] Building PLJava on Solaris issues Content-Type: text/plain; charset="us-ascii" On 03/26/16 18:17, Eugenie V. Lyzenko wrote: >> If so, could you describe the exact failure and the message? > Now let's see what we have if to remove explicit declaring > -R/usr/postgres/9.4-pgdg/lib/64 from aol.properties file: > $ ldd libpljava-so-1.5.0-BETA2.so > libecpg.so.6 => (file not found) > libpgtypes.so.3 => /opt/csw/lib/64/libpgtypes.so.3 > libpq.so.5 => /opt/csw/lib/64/libpq.so.5 > > At least we potentially will have one runtime linkage error. The other > libraries may work and may not properly. Hi, I understand this is what you see when you run ldd on libpljava.so in isolation. However, in operation, that is not what happens. libpljava.so gets dlopen'd into an already-running postgres backend process, where those libraries have already been resolved. Certainly on linux and other OSes where I have tried it, when you actually load pljava into postgres, it succeeds with no difficulty. (The Mac OS X linker even has a nifty option where, at build time, it actually examines the postgres executable to make sure that it really will satisfy pljava's unmet dependencies at the time it loads.) So, if there is an issue here with Solaris, that will mean its behavior is different from the other tested operating systems in that respect. That's not impossible, but it would be helpful if you could report what actually happens when you load that libpljava in a PostgreSQL session. Thanks, -Chap _______________________________________________ Pljava-dev mailing list Pljava-dev@lists.pgfoundry.org http://lists.pgfoundry.org/mailman/listinfo/pljava-dev