Tom Lane wrote:
> Probably so. I had not realized that HP's linker is affected by which
> way the symlinks run, but it appears that it is.
I've just spoken to someone who knows more about the HP-UX toolchain
than I do.
The situation is that the library can have an internal name if the +h
option was provided to ld. Since no name is specified in the link
command in Makefile.shlib for HP-UX, the following (from the ld(1)
manual page) applies instead:
+h internal_name .... That is, if +h is not used, the shared library does not have an
internalname and when an executable is built with the shared library, the linker records the library name that it
looks at....
That doesn't specifically say what happens when the library that it
finds without an internal name is a symbolic link, but doing some
testing shows me that the name used is the name that ld found the
library as, i.e. libpq.sl rather than the desired libpq.sl.3. ld(1)
doesn't read the link when it finds a symbolic link.
My recommendation (with a pinch of salt, since I'm still not a HP-UX
toolchain guru) is to add
+h lib$(NAME)$(DLSUFFIX).$SO_MAJOR_VERSION)
to the HP-UX LINK.shared line in src/Makefile.shlib, and to change the
way the symlinks run as well, so that libpq.sl is a link to the latest
version of libpq that is installed.
I'm not sure where/how the symlink change can be made in the build
environment, but clearly it can be. If I can figure out the answer,
I'll try a test build and see how it goes.
> > 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*.
I'll leave this to your taste and good judgement. The examples above
follow your preference. :-)
Regards,
Giles