Fwd: Re: ERROR: dynamic load not supported

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: Fwd: Re: ERROR: dynamic load not supported
Date: 2003-09-18 13:09:58
Message-ID: 200309180909.58297.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

for future reference

---------- Forwarded Message ----------

Subject: Re: [INTERFACES] ERROR: dynamic load not supported
Date: Wednesday 17 September 2003 15:40
From: Rich Cullingford <rculling(at)sysd(dot)com>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>

Robert Treat wrote:
> I had a similar problem with some pgcrypto functions until i specified
> the specific .so file.
>
> Robert Treat
>
> On Wed, 2003-09-17 at 10:55, Rich Cullingford wrote:
>>All,
>>This is with a new 7.3.4 installation. Every CREATE FUNCTION call I
>>make, e.g.,
>>
>>CREATE FUNCTION plpgsql_call_handler () RETURNS LANGUAGE_HANDLER AS
>> '<absolute-path-to-pg-install>/lib/plpgsql' LANGUAGE C;
>>
>>fails with this error. I know the specification of absolute paths for
>>the library lookup is deprecated, but it's supposed to still work, and,
>>as of last week, did. "I haven't changed anything." :) (But doubtless
>>have done something stupid.)

Robert,
Thanks for replying!

This turned out to be a nasty incompatibility between the way libtool &
autoconf function in GNU and PG. Here's the note that describes the
problem (attached to the RT ticket that records it):

*******
If you configure a shared config.cache for multiple packages, be aware that
Postgres's use of autoconf variables is incompatible with the way they are
used in packages that use libtool.

Specifically, Postgres uses

AC_CHECK_LIB(dl, main)
...
AC_CHECK_FUNCS([cbrt ... dlopen fdatasync])

which adds -ldl to LIBS (if libdl exists) and then searches for the dlopen
function in the current set of LIBS; on systems with dlopen in libdl, this
sets the cache variable $ac_cv_func_dlopen = "yes". If a cached "no" value
is seen, Postgres (maybe incorrectly) believes that dlopen is not
available.

Libtool-based programs, on the other hand, set $ac_cv_func_dlopen = "no"
if dlopen is not present in libc, and use another mechanism to determine if
dlopen is available in libdl instead. If a cached "yes" value is seen,
libtool (maybe incorrectly) believes that -ldl need not be added to LIBS.

Workaround for this is to use separate configure caches for Postgres and
other (libtool-based) programs. You can copy the caches as long as you
filter
out the ac_cv_func_dlopen line using something like:

sed /ac_cv_func_dlopen/d < ../config.cache > config.cache
*****

Watch out if you try to package PG with GNU utilities!
Rich Cullingford
rculling(at)sysd(dot)com

-------------------------------------------------------

--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Browse pgsql-interfaces by date

  From Date Subject
Next Message Paulo Scardine 2003-09-18 18:04:32 Killing the backend to cancel a long waiting query
Previous Message Gaetano Mendola 2003-09-18 12:36:46 Re: observations about temporary tables and schemas