X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id D4CB252BF8 for ; Wed, 13 Jul 2005 14:24:12 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 10349-07 for ; Wed, 13 Jul 2005 17:24:10 +0000 (GMT) Received: from fed1rmmtao09.cox.net (fed1rmmtao09.cox.net [68.230.241.30]) by svr1.postgresql.org (Postfix) with ESMTP id 1FA4F52BEC for ; Wed, 13 Jul 2005 14:24:09 -0300 (ADT) Received: from [192.168.1.200] (really [68.111.226.8]) by fed1rmmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050713172406.SVNA7275.fed1rmmtao09.cox.net@[192.168.1.200]>; Wed, 13 Jul 2005 13:24:06 -0400 Message-ID: <42D54E31.1040508@acm.org> Date: Wed, 13 Jul 2005 10:24:01 -0700 From: TJ O'Donnell Reply-To: tjo@acm.org User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Fuhr , pgsql-general@postgresql.org Subject: Re: [SQL] dynamically loaded functions References: <42D33601.5080605@acm.org> <20050713020847.GA87716@winnie.fuhr.org> In-Reply-To: <20050713020847.GA87716@winnie.fuhr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.032 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200507/453 X-Sequence-Number: 80551 > > 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. >