Re: [INTERFACES] pgaccess troubles on HP-UX - Mailing list pgsql-interfaces
From | Tom Lane |
---|---|
Subject | Re: [INTERFACES] pgaccess troubles on HP-UX |
Date | |
Msg-id | 23053.915467411@sss.pgh.pa.us Whole thread Raw |
In response to | pgaccess troubles on HP-UX ("Stan Brown" <stanb@awod.com>) |
List | pgsql-interfaces |
"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
pgsql-interfaces by date: