Tom Lane wrote:
> John R Pierce <pierce@hogranch.com> writes:
>
>> I have compiled some C (pljava.c) for solaris sparc 64 bit, setup the
>> LD_LIBRARY_PATH so postgres can find it, and try and load it.
>>
>
>
>> me=# CREATE FUNCTION sqlj.java_call_handler() RETURNS language_handler
>> AS 'pljava' LANGUAGE C;
>> ERROR: could not load library "/opt/mystuff/pljava/pljava.so": ld.so.1:
>> postgres: fatal: relocation error: file /opt/mystuff/pljava/pljava.so:
>> symbol Int64GetDatum: referenced symbol not found
>>
>
> This appears to be a consequence of 32-vs-64-bit confusion, ie, your
> pljava.so was built assuming !USE_FLOAT8_BYVAL but the backend was
> built with that symbol defined. Are you still trying to hack your
> way to a solution without making configure run properly? Because
> this is just about the sort of pain I'd expect from that "shortcut".
>
Using the include files provided with the 64bit version is giving me the
wrong Float8 type, yes, as they are the 32bit include files.
I need to build pl/java to run against the binary release of Postgres
for largely political/corporate reasons. this is to be installable as
an addon to an existing large/complex database deployment.
If I build my own ./configure and compile my own postgres binary and use
that to build this, what are the odds the module I compile will work
with the released binary?
If I had the correct include files for the binary release, I would not
be having this problem.