Date: Sat, 23 Dec 2006 13:03:41 -0500
From: L Bayuk <lbayuk@pobox.com>
To: Michael Talbot-Wilson <mtw@view.net.au>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: pgtcl installation problem
Message-ID: <20061223180341.GA402@mail.mindspring.com>
References: <Pine.LNX.4.60.0612232025590.14153@calypso.view.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.60.0612232025590.14153@calypso.view.net.au>
User-Agent: Mutt/1.4.2.2i

On Sat, Dec 23, 2006 at 08:52:15PM +1030, Michael Talbot-Wilson wrote:
> I have installed postgresql 8.2.0 and pgtclng 1.5.3 but the
> installation of pgtclng 1.5.3 is faulty.  I hope someone can tell me
> what I'm doing wrong.
>...
> couldn't load file "/usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so":
> /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so: undefined symbol:
> lo_export
>     while executing
> "load /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so pgtcl"
>     ("package ifneeded" script)
>     invoked from within
> "package require Pgtcl"
>     (file "./see" line 2)

Wow. I have no idea why you would get undefined on (just) the lo_* calls.
As Tom pointed out, those are in the PostgreSQL libpq library, whereas the
Pg_lo_* functions you show as "T" are internal to Pgtclng.

> With nm /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so I see
> 
>          U lo_close
>          ...

This is normal. Those symbols are in libpq and nm will report them as
undefined. You should also see "U" for PQclear, PQexec, and lots more
beginning with "PQ".

First thing to do is what Tom said:
   ldd /usr/local/lib/pgtcl1.5.3/libpgtcl1.5.3.so
Let's see if it can find libpq. (Yes, if not it should have said that when
you did "package require", but who knows.)

I have noticed that the pgtclng build includes the path to libpq (rpath),
where I think the original Pgtcl does not. In my testing, it meant that
original Pgtcl won't run without the PostgreSQL library directory in
LD_LIBRARY_PATH or /etc/ld.so.conf, and my pgtcl-ng won't run if you build
it on one system and use it elsewhere with a different PostgreSQL library
path. I think there are valid points on both sides, but I'm no expert.