Message-ID: <3F8B55F6.2070102@comcast.net>
Date: Mon, 13 Oct 2003 19:48:38 -0600
From: "D. Stimits" <stimits@comcast.net>
Reply-To: stimits@comcast.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021018
MIME-Version: 1.0
To: pgsql-general <pgsql-general@postgresql.org>
Subject: Re: [INTERFACES] more on undefined reference to 'pg_detoast_datum'
References: <3F886324.8020707@comcast.net> <558.1065936082@sss.pgh.pa.us>
	<3F8A64DF.1080008@comcast.net> <14311.1066056160@sss.pgh.pa.us>
In-Reply-To: <3F886324.8020707@comcast.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

 > "D. Stimits"  writes:
 >
 > >... My question is, where the heck is
 > >CurrentMemoryContext and MemoryContextAlloc provided as an
 > >implementation which I can link with?
 >
 >
 > They're inside the backend, and you don't --- you are not trying to
 > build a standalone executable with no unresolved symbols, but a shared
 > library that can be successfully loaded into the backend.  It's okay
 > for such a library to have unresolved references to symbols that will be
 > resolved at load time.
 >
 >             regards, tom lane


Thanks to all that answered this. I found the problem, and it was 
totally unexpected. There were some leftover Makefile lines that were 
used to build a standalone module loader test unit, that test unit does 
not implement palloc. The actual dynamic loadable module was in fact 
working right, but the make was dying early when it so much as 
referenced the old module loader code (a loader used to test/regress 
functions before trying it on a server). I couldn't believe my eyes when 
I saw those old lines in there.

D. Stimits