dynamically loaded functions
I've written some c-functions which depend on my code (gnova.so)
as well as a third-party library of functions (oe_chem.so).
Up until now, I've been preloading (in postgresql.conf) both .so's
and it all works fine. To make it easier for my users to install my stuff,
I'd like to avoid the preloading, but this would
require giving 2 .so names in the CREATE FUNCTION statement (I imagine).
So, what I would like to do is something like this:
CREATE or REPLACE FUNCTION cansmiles(varchar) RETURNS varchar
AS 'gnova,oe_chem', 'oe_cansmiles' LANGUAGE 'c' IMMUTABLE STRICT;
but I get this:
ERROR: could not access file "gnova,oe_chem": No such file or directory
What I'm doing now:
CREATE or REPLACE FUNCTION cansmiles(varchar) RETURNS varchar
AS 'gnova', 'oe_cansmiles' LANGUAGE 'c' IMMUTABLE STRICT;
requires preloading of oe_chem.so to work.
Is there any way I can associate oe_cansmiles with 2 .so's without
preloading?
More info:
oe_cansmiles is in gnova.so, but there are functions
in gnova.so that are in oe_chem.so.
TJ
On Mon, Jul 11, 2005 at 08:16:17PM -0700, TJ O'Donnell wrote:
CREATE or REPLACE FUNCTION cansmiles(varchar) RETURNS varchar
AS 'gnova', 'oe_cansmiles' LANGUAGE 'c' IMMUTABLE STRICT;
requires preloading of oe_chem.so to work.Is there any way I can associate oe_cansmiles with 2 .so's without
preloading?
It sounds like you need to link gnova.so against the other shared
objects so the runtime linker can find them. For examples, see the
Makefiles used by contributed modules like dblink, xml2, and a few
others that link against external libraries.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
It sounds like you need to link gnova.so against the other shared
objects so the runtime linker can find them. For examples, see the
Makefiles used by contributed modules like dblink, xml2, and a few
others that link against external libraries.
That approach is working, but only after much troubles.
I have several 3rd party libraries, some of which call each other.
It appears I need to carefully order the libraries in the
link step, or some needed functions do not get included in the
final .so.
This problem used to crop up all the time way back 20 years ago
with linkers. I thought all this name resolution stuff was all worked
out with modern linkers. I'm "linking" with (linux redhat)
gcc -shared -o my.so my.o my2.o their.a their2.a their3.a
When function x() in their2.a calls something in their.a
(or is it the other way around?)
I get an error from postmaster that my.so cannot be loaded because
function x cannot be found.
If I reverse their.a their2.a in the link command, all is well.
Note: I never use, nor even knew about the exitence of function x() - "they" do.
Any help on how to make this more pain-free?
TJ
Michael Fuhr wrote:
Show quoted text
On Mon, Jul 11, 2005 at 08:16:17PM -0700, TJ O'Donnell wrote:
CREATE or REPLACE FUNCTION cansmiles(varchar) RETURNS varchar
AS 'gnova', 'oe_cansmiles' LANGUAGE 'c' IMMUTABLE STRICT;
requires preloading of oe_chem.so to work.Is there any way I can associate oe_cansmiles with 2 .so's without
preloading?It sounds like you need to link gnova.so against the other shared
objects so the runtime linker can find them. For examples, see the
Makefiles used by contributed modules like dblink, xml2, and a few
others that link against external libraries.
On Wed, 2005-07-13 at 10:24 -0700, TJ O'Donnell wrote:
It sounds like you need to link gnova.so against the other shared
objects so the runtime linker can find them. For examples, see the
Makefiles used by contributed modules like dblink, xml2, and a few
others that link against external libraries.That approach is working, but only after much troubles.
I have several 3rd party libraries, some of which call each other.
It appears I need to carefully order the libraries in the
link step, or some needed functions do not get included in the
final .so.This problem used to crop up all the time way back 20 years ago
with linkers. I thought all this name resolution stuff was all worked
out with modern linkers. I'm "linking" with (linux redhat)
gcc -shared -o my.so my.o my2.o their.a their2.a their3.a
When function x() in their2.a calls something in their.a
(or is it the other way around?)
I get an error from postmaster that my.so cannot be loaded because
function x cannot be found.
If I reverse their.a their2.a in the link command, all is well.
Note: I never use, nor even knew about the exitence of function x() - "they" do.Any help on how to make this more pain-free?
TJ
I don't know much about pgsql but I do know that when linking if module1
needs something in module2 and module2 needs something in module1 then
you can put the the same module in the library link (i.e. '-l') list
more than once.
Show quoted text
Michael Fuhr wrote:
On Mon, Jul 11, 2005 at 08:16:17PM -0700, TJ O'Donnell wrote:
CREATE or REPLACE FUNCTION cansmiles(varchar) RETURNS varchar
AS 'gnova', 'oe_cansmiles' LANGUAGE 'c' IMMUTABLE STRICT;
requires preloading of oe_chem.so to work.Is there any way I can associate oe_cansmiles with 2 .so's without
preloading?It sounds like you need to link gnova.so against the other shared
objects so the runtime linker can find them. For examples, see the
Makefiles used by contributed modules like dblink, xml2, and a few
others that link against external libraries.