Auto-rpath revisited...

[Ian Lance Taylor]

   Date: Fri, 20 Feb 1998 11:25:15 -0800
   From: Lee Iverson <leei@ai.sri.com>

   OK.  I have an implementation of a system for automatically generating
   shared lib rpaths in collect2.  It carefully walks through
   '-L'-specified paths and searches for shared libraries which will
   actually resolve the link search.  This should deal with the
   previously raised objections to automatic techniques which just map -L
   to rpath, and definitely solves the problem of needing LD_LIBRARY_PATH
   in order to even run a minimal C++ program on systems where
   libstdc++.so is not installed in a standard place.

Thanks for doing this.

   1) Do an exhaustive walkthrough of -L/-l pairs, and add to the end of
      any user-supplied rpath an entry for any directory which resolves a
      shared lib link (this is what the implementation now does).

Personally, I think that if the user explicitly specifies -R or
-rpath, you should trust them, and not change its value.  I'm not sure
if that is what you are saying here.  You should only set up the rpath
if the user did not specify one; that is the case where the naive user
can get caught.

(A tool like libtool will cleverly set up the rpath for the installed
directory, even though it is linking against a library in the build
directory, and you do not want to foil libtool by putting the build
directory into the rpath.)

   2) Restrict the auto-rpath generation to only checking against
      system-supplied -L directories (i.e. -L$(exec_prefix)/lib).

I see no need for this restriction.

Ian