pgAccess fails to launch on HPUX

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

Tom Lane writes:

Does anyone object if I modify pgaccess so that it always specifies the
full path to the library?

If I had known that this was possible I would have done it myself already.
;-) This is a good idea in general because in a default installation
pgaccess won't find libpgtcl on any system because it doesn't have the
benefit of the -rpath/-R business. Please review/remove the note at the
end of the pgaccess ref page if you fix this to your satisfaction.

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.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

Does anyone object if I modify pgaccess so that it always specifies the
full path to the library?

If I had known that this was possible I would have done it myself already.
;-) This is a good idea in general because in a default installation
pgaccess won't find libpgtcl on any system because it doesn't have the
benefit of the -rpath/-R business.

Right, even with a cooperative Tcl+kernel, you need to set LD_LIBRARY_PATH
to make pgaccess work. Perhaps this will fix that. AFAICT, specifying
a full path in the Tcl 'load' command is legal on all systems. However,
we still have to rely on the dynamic linker to do the right thing with
the indirect dependency on libpq.so, so there may be systems that still
need LD_LIBRARY_PATH to find libpq.so.

Please review/remove the note at the
end of the pgaccess ref page if you fix this to your satisfaction.

Thanks for the pointer, I probably wouldn't have noticed that. But
given the above consideration, I'm not sure I want to remove the note
yet.

BTW, I'm also thinking about fixing pgaccess so that it honors the
--with-pgport configure setting and PGPORT environment variable, rather
than having the default port number 5432 hard-wired in.

regards, tom lane

"Ross J. Reedstrom" wrote:

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

Yes. The full path to libpgtcl might be specified directly in pgaccess.
But libpq library need to be found automatically because it isn't in a "load"
explicit command.

Constantin Teodorescu

Constantin Teodorescu <teo@flex.ro> writes:

Yes. The full path to libpgtcl might be specified directly in pgaccess.

I have committed pgaccess changes to do this.

But libpq library need to be found automatically because it isn't in a "load"
explicit command.

At least on HPUX 10, this seems to work anyway, presumably because the
correct search path is embedded into libpgtcl.sl. I imagine that not
all platforms have 'rpath' info embedded into shlibs, so there may be
other platforms where you still need to set LD_LIBRARY_PATH to find
libpq.so.

Thought: would it be out of line for pgaccess.sh to set LD_LIBRARY_PATH
explicitly to cover this possibility?

regards, tom lane

If I had known that this was possible I would have done it myself already.
;-) This is a good idea in general because in a default installation
pgaccess won't find libpgtcl on any system because it doesn't have the
benefit of the -rpath/-R business. Please review/remove the note at the

Really? On my RedHat 6.2 derived Linux distribution pgaccess
successfully finds libpgtcl.so without any problem. (using Tcl8.0)
--
Tatsuo Ishii

Tatsuo Ishii writes:

If I had known that this was possible I would have done it myself already.
;-) This is a good idea in general because in a default installation
pgaccess won't find libpgtcl on any system because it doesn't have the
benefit of the -rpath/-R business. Please review/remove the note at the

Really? On my RedHat 6.2 derived Linux distribution pgaccess
successfully finds libpgtcl.so without any problem. (using Tcl8.0)

Then you probably have LD_LIBRARY_PATH set, or you have the linker
configured to look into the directory by default.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

If I had known that this was possible I would have done it myself already.
;-) This is a good idea in general because in a default installation
pgaccess won't find libpgtcl on any system because it doesn't have the
benefit of the -rpath/-R business. Please review/remove the note at the

Really? On my RedHat 6.2 derived Linux distribution pgaccess
successfully finds libpgtcl.so without any problem. (using Tcl8.0)

Then you probably have LD_LIBRARY_PATH set, or you have the linker
configured to look into the directory by default.

I thought the point in these discussions is libpgtl.so could not be
loaded even if LD_LIBRARY_PATH or whatever is set.
--
Tatsuo Ishii

Tatsuo Ishii writes:

I thought the point in these discussions is libpgtl.so could not be
loaded even if LD_LIBRARY_PATH or whatever is set.

No, the point is that we are trying to avoid the requirement that
LD_LIBRARY_PATH has to be set before the system can be used. This works
okay with C linkage programs because of the "rpath" feature, but pgaccess
does not have the benefit of that so we needed another way for it to find
libpgtcl.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/