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