Tom Lane wrote:
John R Pierce <pierce@xxxxxxxxxxxx> 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.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
