Re: hppa*64* and dependent libraries

[John David Anglin]

> Dependent libraries for hppa64* is funky.
> 
> $ cd /tmp/a
> $ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc
> $ elfdump -L lib1.sl | head
> 0       Needed   libc.2
> 1     Soname   lib1.sl.0
> $ cd /tmp/b
> $ ld -b +h lib2.sl.0 -o lib2.sl ../a/lib1.sl obj3.o obj4.o -lc
> $ elfdump -L lib2.sl | head
> 0       Needed   lib1.sl.0
> 1       Needed   libc.2
> 2     Soname   lib2.sl.0
> $ cd /tmp
> $ ld -b +h lib3.sl.0 -o lib3.sl a/lib1.sl b/lib2.sl obj5.o
> ld: Can't find dependent library "libl1.sl.0"
> $ ld -b +h lib3.sl.0 -o lib3.sl -La b/lib2.sl obj5.o
> 
> According to
> http://docs.hp.com/hpux/onlinedocs/B2355-90655/B2355-90655.html:
>  * All DT_NEEDED entries with no "/" in the libname are subject to
>    dynamic path lookup.
> 
> We have two possible solutions:
>   (1) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a ../a/lib1.sl obj3.o obj4.o -lc
>   (2) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a -l1 obj3.o obj4.o -lc
> 
> I've confirmed the above behaviour with a post to the HP-UX Developer
> Mailing List. It's frustrating that even though we explicitly list
> a/lib1.sl in the link line, it doesn't help.
> 
> So, is there anything in libtool to already do this? If not, do we
> adopt solution #1 or #2?

I suggest neither.  I believe that you don't want to try to hardcode
the full path of libraries.  It is better to use "+b" to set the embedded
path.  This is equivalent to the -rpath option when GNU ld is used.
The standard dynamic path search order is LD_LIBRARY_PATH, SHLIB_PATH
and then the embedded path.  The default is for all three to be enabled.
The enables and search order can be changed with chatr if desired.

I personally like the dynamic path lookup and dislike the hardcoded
paths used with the 32-bit SOM linker.  With the hardcoded paths, it
not possible to move libraries.  It can also cause other problems.
An example is GCC.  GCC builds paths relative to its tool directory
which is installed in a version specific directory.  This caused
libraries like libstdc++.sl to have dependencies which included the
path to the gcc tool directory.  If you removed the gcc tool directory,
then applications linked with libstdc++.sl no longer worked.  I
removed the dot dots from the dependencies a few months ago.  The
downside in doing this is that it is now no longer possible to move
the gcc tool directory by inserting a symbolic link.

Dave
-- 
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)