Обсуждение: Re: [SQL] dynamically loaded functions

 >
 > 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.
>

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.



>
> 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.
> >
>