> 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 [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool