Auto-rpath revisited...

[Todd Vierling]

On 21 Feb 1998, Alexandre Oliva wrote:

: >> 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.
: 
: > But this looses when the library isn't installed yet.
: 
: If the library isn't installed yet, you'll *have* to specify its
: runtime path, so the right thing to do is to not guess library path if
: the user specifies it himself.  However, for libraries that are
: implicitly linked in by the compiler, it is reasonable that the
: compiler provides the shared library runtime path itself.

What do you do in a cross-compile environment?

I have a, say, NetBSD/i386 system which cross compiles for
sparc-sun-solaris2.5.1.  What use would I have to have
/usr/local/sparc-sun-solaris2.5.1/gcc-lib in my rpath--_particularly_ if my
/usr/local is NFS?  Bah, I'll take my nfs server and throw it out the window
first. 

I had this problem with the SunOS incantation of gld and discussed it on the
list.  I got so fed up with auto-rpath that I completely zapped the whole
slew of code out of my loccal copy of gld and I am glad that it doesn't ever
create rpaths without my explicit permission.  This should be a
configure-time option, or at the very least a command line option.  (For a
while, adding '-rpath=' to the gcc specs link line was sufficient, but it
still left some to be desired.)

Remember, ELF and SunOS ld.so dynamic linkers know the system directories
(typically /usr/lib) implicitly and they don't _need_ an rpath unless shlibs
are installed in a "funny" place.  Specifying one for the sake of runtime
happiness is nice for the naive user, but the experienced user should know
how to install libstdc++ in a system directory and disable a spurious rpath. 

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)