From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stan Brown <stanb@awod.com>
Cc: pgsql-interfaces@hub.org
Subject: Re: [INTERFACES] pgaccess troubles on HP-UX
Date: Mon, 04 Jan 1999 11:30:11 -0500
Message-ID: <23053.915467411@sss.pgh.pa.us> (raw)
In-Reply-To: <199901040319.WAA14103@hub.org>
"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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, stanb@awod.com, pgsql-interfaces@hub.org
Subject: Re: [INTERFACES] pgaccess troubles on HP-UX
In-Reply-To: <23053.915467411@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox