more on undefined reference to 'pg_detoast_datum' and libpq

"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 #

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