Обсуждение: more on undefined reference to 'pg_detoast_datum' and libpq

Apparently in PosgreSQL 7.2.3 (the Redhat 7.3 version, which has some 
patching involved), pg_detoast_datum is defined in fmgr backend code, 
but this function is not defined anywhere in any library, especially not 
libpq. It is the necessity to use fmgr.h functions that brings about the 
need to have pg_detoast_datum. The V1 interface itself requires fmgr.h, 
this is where PG_FUNCTION_INFO_V1 is declared, along with other V1 
macros. My guess is that pg_detoast_datum should be in a library 
somewhere, but manually compiling PostgreSQL 7.2.3 source with 
unstripped libraries shows that no dynamic library produced from the 
source build contains the necessary functions. There does not appear to 
be any libfmgr.so (of any version), unless there is some configure 
option I am missing.

How do I get around this without using non-Redhat packages and without 
forcing users to install another version of PostgreSQL? At this point it 
looks like there is no choice but to use the V0 interface to libpq and 
develop separate projects for other versions of linux PostgreSQL that 
have more recent versions.

D. Stimits

"D. Stimits" <stimits@comcast.net> writes:
> Apparently in PosgreSQL 7.2.3 (the Redhat 7.3 version, which has some 
> patching involved), pg_detoast_datum is defined in fmgr backend code, 
> but this function is not defined anywhere in any library, especially not 
> libpq.

Of course not; it's a backend function.  Your problem is that you are
trying to build a server-side function as though it were a client
application.  You're linking to an inappropriate set of libraries.
See the contrib modules for numerous examples of correct link setup
for server-side functions.
        regards, tom lane

Tom Lane wrote:

> "D. Stimits"  writes:
>
> >Apparently in PosgreSQL 7.2.3 (the Redhat 7.3 version, which has some
> >patching involved), pg_detoast_datum is defined in fmgr backend code,
> >but this function is not defined anywhere in any library, especially not
> >libpq.
>
>
> Of course not; it's a backend function.  Your problem is that you are
> trying to build a server-side function as though it were a client
> application.  You're linking to an inappropriate set of libraries.
> See the contrib modules for numerous examples of correct link setup
> for server-side functions.
>
>             regards, tom lane
>

My attempt to try linking against some of the client libraries was to 
find a link source for CurrentMemoryContext and MemoryContextAlloc. The 
headers for backend development include prototypes as extern for many 
functions, such as those above. It's painfully obvious that glibc does 
not provide these definitions, and it is obvious also that the client 
libraries do not implement these. My question is, where the heck is 
CurrentMemoryContext and MemoryContextAlloc provided as an 
implementation which I can link with? It looks like the Redhat 7.3 
(PostgreSQL 7.2.3) devel rpm package is missing the library needed. Or 
perhaps there is no such library, and I'd be required to drop my code 
into the complete source of the SQL server itself, which is most 
inconvenient. How the heck do I find an implentation of 
CurrentMemoryContext and MemoryContextAlloc? Running ldd on sample 
contrib libraries leads me to believe that in order to build this code, 
I must have a built full PostgreSQL source installed and configured, and 
that these functions are not available as a linkable library. Which .o 
object file would I link? Why isn't CurrentMemoryContext or 
MemoryContextAlloc available in a linkable library instead?

D. Stimits

"D. Stimits" <stimits@comcast.net> 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

D. Stimits wrote:

> My attempt to try linking against some of the client libraries was to 
> find a link source for CurrentMemoryContext and MemoryContextAlloc. The 
> headers for backend development include prototypes as extern for many 
> functions, such as those above. It's painfully obvious that glibc does 
> not provide these definitions, and it is obvious also that the client 
> libraries do not implement these. My question is, where the heck is 
> CurrentMemoryContext and MemoryContextAlloc provided as an 
> implementation which I can link with? It looks like the Redhat 7.3 
> (PostgreSQL 7.2.3) devel rpm package is missing the library needed. Or 
> perhaps there is no such library, and I'd be required to drop my code 
> into the complete source of the SQL server itself, which is most 
> inconvenient. How the heck do I find an implentation of 
> CurrentMemoryContext and MemoryContextAlloc? Running ldd on sample 
> contrib libraries leads me to believe that in order to build this code, 
> I must have a built full PostgreSQL source installed and configured, and 
> that these functions are not available as a linkable library. Which .o 
> object file would I link? Why isn't CurrentMemoryContext or 
> MemoryContextAlloc available in a linkable library instead?

I am still confused about what you're trying to build.

Anyhow, CurrentMemoryContext and MemoryContextAlloc are global symbols 
of the servers backend memory management system. If you're building a 
function that you plan to load dynamically into the database server 
process via CREATE FUNCTION, then you will definitely NOT link against 
libpq and should follow the plenty examples as suggested by Tom.

If you are developing a client application that will connect to a 
backend via the libpq client library, than you don't have these 
functions/globals available. We do not provide this memory management 
system as a standalone, linkable library.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #