From: | thhal at mailblocks(dot)com (Thomas Hallgren) |
---|---|
To: | |
Subject: | [Pljava-dev] java.sql.SQLException: ERROR:could not loadlibrary"/usr/local |
Date: | 2005-04-01 21:49:27 |
Message-ID: | 424DC1E7.4040803@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pljava-dev |
Gulden wrote:
> 3. Postgresql doesn't care about the LD_LIBRARY_PATH, it has it own
>LD_LIBRARY_PATH!!!
>
>
Just to clarify.
PostgresSQL uses the postgresql.conf setting "dynamic_library_path" to
find add-on modules. libpljava.so is such a module. PostgreSQL will load
such modules by assembling absolute paths that it sends that to the
dynamic loader (dlopen on Linux). So far, the LD_LIBRARY_PATH has not
been used at all.
When libjava.so has been successfully loaded, it will try to initialize
the Java VM. That, in turn, will invoke the loader again. This time
however, the loader is not explicitly invoked from code and the loader
will utilize the LD_LIBRARY_PATH that is in effect for the backend
process in order to find the libjvm.so and other shared objects that the
libjvm.so might need in turn.
> Where can I configure that???
>
You define the relevant LD_LIBRARY_PATH by exporting it just before you
start the postmaster deamon. That deamon will then propagate the setting
to all backend processes that it spawns, thus making the LD_LIBRARY_PATH
visible to libpljava.so.
- thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Gulden | 2005-04-03 18:18:12 | [Pljava-dev] java.sql.SQLException: ERROR:could not loadlibrary"/usr/local |
Previous Message | Gulden | 2005-04-01 19:14:43 | [Pljava-dev] java.sql.SQLException: ERROR: could not loadlibrary"/usr/local |