libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hppa*64* and dependent libraries


From: Albert Chin
Subject: Re: hppa*64* and dependent libraries
Date: Sat, 14 Dec 2002 17:18:08 -0600
User-agent: Mutt/1.4i

On Sat, Dec 14, 2002 at 03:22:42AM -0600, Albert Chin wrote:
> 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?

Ok, there is another option:
  (3) ld -b +h lib2.sl.0 -o lib2.sl +b /tmp/a ../a/lib1.sl obj3.o obj4.o -lc

I've chosen to use option #3 because libtool has code to handle most
of it. I've configure hppa64 such that:
  hardcode_direct=no
  hardcode_into_libs=yes
  hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'

However, I now have the problem that I need '+b' for ld and '-Wl,+b'
for cc. Because there is not a separate $hardcode_libdir_flag_spec for
ld/cc, I have to hack libtool.m4 like:
  case "${LD}" in
  */ld*)
    wl=
  esac
  eval dep_rpath=\"$hardcode_libdir_flag_spec\"

This is gross. I have no problem modifying $hardcode_libdir_flag_spec
so it's rewritten as:
  hardcode_libdir_flag_spec="`if linking with ld; then +b $libdir;
  else ${wl}+b ${wl}$libdir`"
However, I don't see an easy way to detect at runtime whether or not
we're using ld/cc to link/compile. So, what do I do? Should I
introduce a separate hardcode_libdir_flag_spec for creating shared
libraries and one for creating programs?

BTW, this is relative to 1.4 but the same problems no doubt exist in
HEAD.

-- 
albert chin (address@hidden)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]