Received: from wallace.ece.rice.edu (wallace.ece.rice.edu [128.42.12.154])
	by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f17Inix88976;
	Wed, 7 Feb 2001 13:49:44 -0500 (EST)
	(envelope-from reedstrm@rice.edu)
Received: by rice.edu via sendmail from stdin
	id <m14QZeT-000LEJC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
	for pgsql-hackers@postgresql.org; Wed, 7 Feb 2001 12:49:13 -0600 (CST)
Date: Wed, 7 Feb 2001 12:49:13 -0600
From: "Ross J. Reedstrom" <reedstrm@rice.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] pgAccess fails to launch on HPUX
Message-ID: <20010207124913.A29490@rice.edu>
Mail-Followup-To: Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
References: <6811.981570898@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <6811.981570898@sss.pgh.pa.us>;
	from tgl@sss.pgh.pa.us on Wed, Feb 07, 2001 at 01:34:58PM -0500
X-Archive-Number: 200102/238
X-Sequence-Number: 4369

On Wed, Feb 07, 2001 at 01:34:58PM -0500, Tom Lane wrote:
> I thought I'd tried pgAccess back in the dim past with success, but as
> of current sources it fails on HPUX 10.20 and Tcl 8.3.2:
> 
<SNIP problem with dynamic load and Tcl>

> And the reason for *that* is that Tcl doesn't pass the DYNAMIC_PATH flag
> to shl_load().  I find that sourceforge.net already has a couple of bug
> reports posted on this, so perhaps the Tcl guys will get their act
> together and add the flag in Tcl 8.4, but in the meantime I think we
> have very little choice except to specify the full path to the library
> in pgaccess' load command.

Yep, the Tcl team changed dynamic loading in 8.2->8.3 This bit me on NT,
first.

> 
> Does anyone object if I modify pgaccess so that it always specifies the
> full path to the library?  That seems like it'd be a good idea even on
> OSes without this quirk, because it'd ensure getting the matching
> version of libpgtcl and libpq even if your SHLIB_PATH/LD_LIBRARY_PATH
> points to some other version.

Sounds like a good idea, to me. Getting the wrong library loaded leads to
non-obvious error messages, as well.

Ross