shared libraries, dynamic link path propagation

[Harry Kao]

Hello.  I'm having a problem that seems very similar to the one
discussed here

http://lists.gnu.org/archive/html/bug-libtool/2006-01/msg00021.html

where the dynamic link paths aren't being propagated from shared
libraries to programs.  I looked at the code and it seems that the -R
dependencies are being dropped here:

  for deplib in $tmp_libs; do
    # FIXME: Pedantically, this is the right thing to do, so
    #        that some nasty dependency loop isn't
    #        accidentally
    #        broken:
    #new_libs=3D"$deplib $new_libs"
    # Pragmatically, this seems to cause very few problems in
    # practice:
    case $deplib in
    -L*) new_libs=3D"$deplib $new_libs" ;;
### No action is being taking on -R below. -hkao
    -R*) ;;
    *)
      # And here is the reason: when a library appears more
      # than once as an explicit dependence of a library, or
      # is implicitly linked in more than once by the
      # compiler, it is considered special, and multiple
      # occurrences thereof are not removed.  Compare this
      # with having the same library being listed as a
      # dependency of multiple other libraries: in this case,
      # we know (pedantically, we assume) the library does not
      # need to be listed more than once, so we keep only the
      # last copy.  This is not always right, but it is rare
      # enough that we require users that really mean to play
      # such unportable linking tricks to link the library
      # using -Wl,-lname, so that libtool does not consider it
      # for duplicate removal.
      case " $specialdeplibs " in
      *" $deplib "*) new_libs=3D"$deplib $new_libs" ;;
      *)
        case " $new_libs " in
        *" $deplib "*) ;;
        *) new_libs=3D"$deplib $new_libs" ;;
        esac
        ;;
      esac
      ;;
    esac
  done

At least, when I run 'libtool --debug' that's near the last place the
runtime path is mentioned in the output.  I also came across this
message, which claims that -R is handled through another mechanism:

http://lists.gnu.org/archive/html/libtool-patches/2003-03/msg00086.html

That does not seem to be the case at this time.  Did the code break
sometime between these two messages?  Can someone suggest a fix?

Thanks.  I hope this was clear.

Harry
-- 
:: Tue, 24 Oct 2006 08:50:37 -0700 ::

signature.asc
Description: Digital signature