Auto-rpath revisited...

[Lee Iverson]

In message < 199802211959.OAA06562@subrogation.cygnus.com > you write:
>    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.

But I don't want you to shut up, I want to get this right.  What do
you want to be saved from?  As I said before, any rpath entries the
user specifies are retained and have highest priority.  I don't really
think in terms of *changing* the user-supplied rpath, just *augmenting*
it if and only if necessary.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307