Skip site navigation (1) Skip section navigation (2)

HP-UX shared library installation is incorrect

From: Giles Lean <giles(at)nemeton(dot)com(dot)au>
To: pgsql-hackers(at)postgresql(dot)org
Subject: HP-UX shared library installation is incorrect
Date: 2002-12-23 02:24:44
Message-ID: 136.1040610284@hpchs.cup.hp.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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


Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-12-23 02:55:28
Subject: Re: HP-UX shared library installation is incorrect
Previous:From: Christopher Kings-LynneDate: 2002-12-23 01:35:38
Subject: Re: EXECUTE status (was Re: [ODBC] About server side prepare)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group