Thread: pgAccess fails to launch on HPUX
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:
$ pgaccess regression
Error in startup script: couldn't load file "libpgtcl.sl": no such file or directory while executing
"load libpgtcl[info sharedlibextension]" (procedure "main" line 3) invoked from within
"main $argc $argv" (file "/home/postgres/testversion/share/pgaccess/main.tcl" line 249)
$
The problem here is that Tcl does not do dynamic path searching, even
if you give it the necessary environment-variable setting:
$ SHLIB_PATH="/home/postgres/testversion/lib:." wish
% load libpgtcl.sl
/usr/lib/dld.sl: Can't open shared library: libpgtcl.sl
/usr/lib/dld.sl: No such file or directory
couldn't load file "libpgtcl.sl": no such file or directory
% load /home/postgres/testversion/lib/libpgtcl.sl
[ works fine ]
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.
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.
regards, tom lane
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/