Auto-rpath revisited...

Ian Lance Taylor ian@cygnus.com
Sat Feb 21 14:20:00 GMT 1998


   Date: Sat, 21 Feb 1998 11:36:00 -0800
   From: Lee Iverson <leei@ai.sri.com>

   2) I agree with Alexandre, and respond to Ian by suggesting that I add
      an option that turns off the auto-rpath behaviour for the
      sophisticated user who is actually managing this properly.  As it
      currently stands, the implementation searches user-supplied rpath
      entries *before* searching the -L paths and adds needed directories
      onto the *end* of the user-supplied rpath.

      If you really are an Ian Taylor, specifying a complete rpath will
      thus obviate the need to add anything to the rpath.  Beyond that, I
      would expect it to be exceedingly unusual for a user to
      deliberately want to leave a shared library unresolved by the
      rpath.

It's not unusual, because shared libraries are often found in the
build directory.  Skipping relative paths doesn't save you, because in
a complex build paths are often canonicalized so that you don't have
to remember how many `../'s to add.

As previously noted, I feel that changing a user specified rpath
option is surprising.  Users who specify rpath already knows what they
are doing.  The purpose of this change is to help naive users, and
users who specify rpath are not naive.

In any case, I think I've made my points, such as they are, and I'll
try to shut up now.

Ian



More information about the Gcc mailing list