Thread
-
HP-UX shared library installation is incorrect
Giles Lean <giles@nemeton.com.au> — 2002-12-23T02:24:44Z
Hi all, I'm planning an upgrade from 7.2.3 to 7.3.1 on some HP-UX systems. With the major number bump in 7.3.1 I was expecting to be able to do this upgrade without a flag day to re-compile clients, however due to misnaming of the PostgreSQL shared libraries on HP-UX I can't. A summary of the problem is that libraries are installed in such a way that clients link to 'libpq.sl' et al and not to the versioned library names such as 'libpq.2'. I doubt that this is solely a problem with my installation, but in case it is here is the configure command line I use: CC=cc CFLAGS="-O" ./configure --prefix=/opt/pgsql-7.3.1 \ --with-includes=$HOME/include --with-libraries=$HOME/lib The extra includes and libraries are to pick up libz and libreadline. I am building on HP-UX 11.11 with the HP ANSI C compiler. The problem is similar with both 7.2.3 and 7.3.1. template1=> select version(); version --------------------------------------------------------------- PostgreSQL 7.2.3 on hppa2.0w-hp-hpux11.11, compiled by cc -Ae (1 row) Below are the details as I understand them currently. There appear to be two problems. I've not yet investigated to find out if only one of them is the root cause. 1. the libraries are installed with their base names such as 'libpq.sl' being regular files, with versioned names being symbolic links to the base names: $ ls -l libpq* -rw-r--r-- 1 root users 103544 Oct 6 14:54 libpq.a -r-xr-xr-x 1 root users 102400 Oct 6 14:54 libpq.sl lrwxr-xr-x 1 root users 8 Oct 6 14:54 libpq.sl.2 -> libpq.sl This should be the other way around: $ ls -l libc.2 libc.sl -r-xr-xr-x 1 bin bin 1843200 Jul 30 2001 libc.2 lrwxr-xr-x 1 root root 15 Apr 18 2002 libc.sl -> /usr/lib/libc.2 2. the versioned names are possibly incorrect: 'libpq.sl.2' should be 'libpq.2' by analogy to the libc example above. The effect of these problems is that client programs linked to these libraries link to the non-versioned names: $ ldd psql /usr/lib/libm.2 => /usr/lib/libm.2 /usr/lib/libnsl.1 => /usr/lib/libnsl.1 /usr/lib/libxti.2 => /usr/lib/libxti.2 /usr/lib/libdld.2 => /usr/lib/libdld.2 /usr/lib/libc.2 => /usr/lib/libc.2 /usr/lib/libdld.2 => /usr/lib/libdld.2 /usr/lib/libgen.2 => /usr/lib/libgen.2 /usr/lib/libc.2 => /usr/lib/libc.2 ../../../src/interfaces/libpq/libpq.sl => /opt/pgsql-7.2.3/lib/libpq.sl /usr/lib/libnsl.1 => /usr/lib/libnsl.1 (Aside: the ../../../src/... stuff is ugly, but harmless as far as I know.) Looking at the build process I see that Makefile.shlib can install either the versioned names or the base names: I don't yet understand why it chooses to install the base names on HP-UX. On NetBSD it does it the other way around. Someone familiar with the build process might know what the cause is here? Dropping the ".sl" from the name might be trickier, since it is expected to be present as a suffix on the base name but not included in the versioned names. Wrong: $ gmake -n install /bin/sh ../../../config/mkinstalldirs /opt/pgsql-7.3.1/lib/pa20_64 /opt/pgsql-7.3.1/include /opt/pgsql-7.3.1/include/internal /bin/sh ../../../config/install-sh -c -m 644 libpq.a /opt/pgsql-7.3.1/lib/pa20_64/libpq.a /bin/sh ../../../config/install-sh -c -m 555 libpq.sl /opt/pgsql-7.3.1/lib/pa20_64/libpq.sl cd /opt/pgsql-7.3.1/lib/pa20_64 && \ rm -f libpq.sl.3 && \ ln -s libpq.sl libpq.sl.3 /bin/sh ../../../config/install-sh -c -m 644 ./libpq-fe.h /opt/pgsql-7.3.1/include /bin/sh ../../../config/install-sh -c -m 644 ./libpq-int.h /opt/pgsql-7.3.1/include/internal /bin/sh ../../../config/install-sh -c -m 644 ./pqexpbuffer.h /opt/pgsql-7.3.1/include/internal Using NetBSD as an example, it's seen that the symbolic links are generated the other way around: $ gmake -n install /bin/sh ../../../config/mkinstalldirs /usr/local/pgsql-7.3/lib /usr/local/pgsql-7.3/include /usr/local/pgsql-7.3/include/internal /bin/sh ../../../config/install-sh -c -m 644 libpq.a /usr/local/pgsql-7.3/lib/libpq.a /bin/sh ../../../config/install-sh -c -m 755 libpq.so.2.2 /usr/local/pgsql-7.3/lib/libpq.so.2.2 cd /usr/local/pgsql-7.3/lib && \ rm -f libpq.so.2 && \ ln -s libpq.so.2.2 libpq.so.2 cd /usr/local/pgsql-7.3/lib && \ rm -f libpq.so && \ ln -s libpq.so.2.2 libpq.so /bin/sh ../../../config/install-sh -c -m 644 ./libpq-fe.h /usr/local/pgsql-7.3/include /bin/sh ../../../config/install-sh -c -m 644 ./libpq-int.h /usr/local/pgsql-7.3/include/internal /bin/sh ../../../config/install-sh -c -m 644 ./pqexpbuffer.h /usr/local/pgsql-7.3/include/internal If fixing this isn't obvious to someone, I'll investigate in detail in the new year. I can see no workaround for existing installations. New installations will want to adjust the libraries before linking clients to them. Regards, Giles -
Re: HP-UX shared library installation is incorrect
Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-23T02:55:28Z
Giles Lean <giles@nemeton.com.au> writes: > 1. the libraries are installed with their base names such as > 'libpq.sl' being regular files, with versioned names being > symbolic links to the base names: > This should be the other way around: Probably so. I had not realized that HP's linker is affected by which way the symlinks run, but it appears that it is. > 2. the versioned names are possibly incorrect: 'libpq.sl.2' should be > 'libpq.2' by analogy to the libc example above. This I disagree with: I consider HP's naming convention ugly and misleading. ".sl" should be in the name *somewhere*. The open-source libraries I have on my machine seem to mostly put the version number after .sl, eg lrwxrwxrwx 1 gnu users 14 Apr 27 2000 libgdbm.sl@ -> libgdbm.sl.2.0 lrwxrwxrwx 1 gnu users 14 Apr 27 2000 libgdbm.sl.2@ -> libgdbm.sl.2.0 -r-xr-xr-x 1 gnu users 45203 Nov 18 1999 libgdbm.sl.2.0* I'd be in favor of following this convention. regards, tom lane