Re: Libtool misfeature on HP-UX

[Schleicher Ralph (LLI)]

Martin Frydl <address@hidden> writes:

[Note: I've exchanged private email with Martin about the subject
and this response to the list should be considered as a summary.]

> I've used the examples you've supplied and removed -avoid-version from
> Makefile.am. This resulted in generating libraries with version info,
> i.e. libfoo.sl.0.0 and libbar.sl.0.0 along with all the links. When
> (re)linking, libtool passes the library name without version, e.g.
> libfoo.sl. However, the executable (or library) contains reference to
> library with major number, e.g. libfoo.sl.0.

This is IMHO an inconsistency in Libtool and should be fixed by the
maintainers.  Libtool creates a shared library with version number
information, e.g., libfoo.sl.0.  After installation, we get

        libfoo.sl -> libfoo.sl.0        # symlink
        libfoo.sl.0                     # regular file (soname)
        libfoo.sl.0.0 -> libfoo.sl.0    # symlink

When Libtool relinks a program, it links against /path/to/libfoo.sl
(symlink file name) instead of /path/to/libfoo.sl.0 (regular/soname
file name).

> I've updated your patches to support also this situation. However, there
> is no information about the library version info in relink command. I've
> found a "dirty" trick to avoid this. In "for" look where you call chatr
> for all the libraries I call it for libname*. For example if variable i
> contains /.../libfoo.sl, chatr will be called for all the libraries
> because shell will expand * to names of all libraries found in the
> directory: libfoo.sl, libfoo.sl.0 and libfoo.sl.0.0.

This fixes the problem described above but can not be used for
production (consider the case with multiple soname versions of the
same library, e.g., libfoo.sl.0 and libfoo.sl.1).  Changing Libtool
as described above is the right thing.

> I've also added chatr +s enable xxx to the commands. This will enable
> SHLIB_PATH use for the executable or library. With this you don't need
> to export LDOPTS.

This is a good idea but `chatr +b enable +s enable ...' is better.
Martin also proposed adding the +s option to the link command, e.g.,

        archive_cmds='$LD -b +h $soname +b $install_libdir +s ...

I see no need for that, because

     a) running `chatr +b enable +s enable ...' has the same effect.
        Since we have to run this command for executable files in any
        case, we can run it for shared libraries, too, making the
        procedure unique for both kinds of relinking.
     b) uninstalled shared library don't need `$LD +s ...', they work
        well without SHLIB_PATH support.

Here is an updated version of my test bench including Martin's
extensions.

foobar-2002-06-03.tar.gz
Description: foobar-2002-06-03.tar.gz

ATT00979.ATT
Description: ATT00979.ATT