Auto-rpath revisited...

[Jim Wilson]

Making a shared libstdc++ work better with gcc is an important problem to
solve, but adding automatic -rpath options by default is probably not a good
way to solve it.

There has already been a lot of discussion pointing out that we shouldn't add
any automatic rpath options if the user specified one.  This is because this
will break some features of shared libraries for expert users.  However, I
don't think anyone has explored just what this involves.  Clearly, we need to
check for command line options -Wl,-rpath,foo.  However, we also need to
check for environment variables.  Just checking the Solaris 2.5.1 ld man
page, I see the following environment variables that appear to be relevant:
LD_LIBRARY_PATH, LD_OPTIONS, LD_PRELOAD, LD_RUN_PATH.  If any of these
environment variables are defined, then we have to check them to see if it
is still safe to add auto-rpath options.  We also need to handle the Solaris 2
-R linker option, and any other options that may be relevant such as -i,
-Bstatic, and -r.  If we don't do all of this, then gcc will not be a drop in
replacement for the Sun C compiler.  And this is just one operating systems.
There will be a different set of linker options and linker environment
variables for every systems.  Once we start encoding this knowledge of linkers
into collect, it will become less portable, harder to maintain, and more
likely to break with a minor OS revision.

A better solution is to add the directory we need to the run-time linkers
default search path.  On some systems, like Linux and SunOS4, this means
running ldconfig.  Yes, this requires root access, but that isn't an
unreasonable requirement for someone who really wants to solve this problem
correctly.  Other major packages (like X11) have the same requirement if
shared libraries are being used.  If someone wants a shared libstdc++ and
can't get root, then we should tell them to set an appropriate environment
variable.

Nowadays, many people are just going to install gcc from a binary package
anyways,  so it is only the package maintainers who need to worry about making
sure that the package sets the dynamic linker's default search path correctly.
If this gets to be a problem, we could perhaps start making our own packages
available in addition to the sources.

I can see some use for having an option that enables auto-rpath.  That would
make it easier for gcc developers and testers who might have multiple or
temporary gcc install trees where ldconfig would be inconvenient or might
not work.  But I don't think this should be the default, because it breaks
the way that shared libraries were designed to work.

Jim