Auto-rpath revisited...

[Marc Espie]

In article < Pine.NEB.3.96.980223094925.12722D-100000@like.duh.org >,
Todd Vierling <tv@pobox.com> wrote:

>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. 

Thanks to diplomacy problems, the `experienced user' doesn't always have
the rights to install libstdc++ in a system directory, in which case having
to hack g++ / rpaths manually is no fun.  Especially when said experienced
user is more interested in using a better C++ compiler than tracking this
sort of thing all over the place.  

If you prefer, having this as a configure option looks quite reasonable to
me, especially IF it's documented.  What should at least be possible is to
install egcs as joe-average-user, WITHOUT having to be root and adding 
libstdc++.so in a system directory, or adding a new directory to ldconfig,
so that it can be used by several people as a drop-in replacement for the
old g++, without having to go back AND coach people in the use of
-Xlinker -rpath.

Another point:   trying out egcs may also mean trying to compile as many
packages as possible with it. Some of them use autoconfig extensively, know
already a lot about shared libraries and rpath options, and will try to
impose their view on the matter.  IF libstdc++.so does NOT appear as a
`silent' drop-in, even when it is not in the system directory, this means
lots of hackings with the configure scripts/Makefile whatever if you don't
happen to live in an enlightened place where sysadmins trust you.

The only reasonable solution then would be to replace g++ with a smart enough
script, or to hack its specs (or collect2) so that use of libstdc++ will be
transparent. In that case, it's simpler to get it once and for all inside
egcs as a configure option, isn't it ?