"Stan Brown" <stanb@awod.com> writes:
> Ok, I have finally gotten libpgtcl compiled under HP-UX 10.20. Now I am
> having trouble with pgaccess using it. Heres what happens when I run
> pgaccess:
> Error in startup script: couldn't load file
> "/data/pgtest/lib/libpgtcl.sl": no such file or directory
> But, it does exist:
> $ ls -l /data/pgtest/lib/libpgtcl.sl
> -r-xr-xr-x 1 postgres users 61517 Jan 3 21:48 /data/pgtest/lib/libpgtcl.sl
The error message is misleading --- what I think it is really
complaining about is that it can't find a shlib that libpgtcl.sl
depends on. Namely, libpq.sl.
If you run chatr ("ldd" to any non-HPUXers listening) you will probably
see something like:
$ chatr /usr/local/pgsql/lib/libpgtcl.sl
/usr/local/pgsql/lib/libpgtcl.sl:
shared library
shared library list:
dynamic ../libpq/libpq.sl
which is a correct relative path to libpq.sl from where libpgtcl.sl is
built, but it's wrong for the installed copy. So the dynamic linker
fails to find libpq.sl when trying to load the installed copy of
libpgtcl.sl.
This is a generic problem with cross-references between shared libraries
on many Unix systems. I believe the only way we're really going to fix
it is to use GNU "libtool" to build our shared libraries. (The way
libtool fixes it is that during the "make install" pass, *after* it has
installed libpq.sl, it relinks libpgtcl.sl using an absolute path to the
installed copy of libpq.sl, then installs that version of libpgtcl.sl.
Ugly, ain't it?) I have been planning to put libtool into the 6.5
source tree, but do not want to risk retrofitting it into 6.4.
A short-term workaround is to make the calling application's dynamic
search path for shlibs include the directory in which libpq.sl exists.
That's what we do for all the applications built by the Postgres
makefiles. For example, on HPUX:
$ chatr /usr/local/pgsql/bin/pgtksh
/usr/local/pgsql/bin/pgtksh:
shared executable
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path enabled first /usr/local/pgsql/lib
shared library list:
static pgtksh
dynamic ../../interfaces/libpgtcl/libpgtcl.sl
dynamic ../../interfaces/libpq/libpq.sl
dynamic /usr/lib/libX11.sl
dynamic /usr/lib/libdld.sl
dynamic /lib/libcurses.sl
dynamic /lib/libc.sl
shared library binding:
deferred
Those relative paths only work when the executable is sitting in the
build directory. After install, it works because the dynamic linker
makes a second try with the "embedded search path" (and, evidently,
just the base name of the target library). There are comparable
kluges in most of the other Unixes we support --- many of them don't
work at all unless the user provides an environment variable with
the right search path.
Again, libtool would improve matters by building an installable
executable with absolute paths to the shlibs it depends on.
> Seems to me that I remeber having built a wish, in the past that
> included these functions, so that loading this library was not
> required. Any truth to this?
pgtksh should have been built for you if configure found Tk and X
libraries. I'd use that, for now.
regards, tom lane