From: Robert Treat <xzilla@users.sourceforge.net>
Subject: Fwd: Re: ERROR: dynamic load not supported
Date: Thu, 18 Sep 2003 09:09:58 -0400
User-Agent: KMail/1.5
To: pgsql-interfaces@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200309180909.58297.xzilla@users.sourceforge.net>

for future reference

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

Subject: Re: [INTERFACES] ERROR: dynamic load not supported
Date: Wednesday 17 September 2003 15:40
From: Rich Cullingford <rculling@sysd.com>
To: Robert Treat <xzilla@users.sourceforge.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@sysd.com

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

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