From: thhal at mailblocks.com (Thomas Hallgren)
Date: Fri, 01 Apr 2005 23:49:27 +0200
Subject: [Pljava-dev] java.sql.SQLException:
	ERROR:could	not	loadlibrary"/usr/local
In-Reply-To: <200504011906.j31J64nn013428@localhost.localdomain>
References: <200504011906.j31J64nn013428@localhost.localdomain>
Message-ID: <424DC1E7.4040803@mailblocks.com>

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