>
> 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:
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.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
