Re: Shared library runpath trouble in Solaris.

[Ian Lance Taylor <ian at cygnus dot com>]

   From: Alexandre Oliva <oliva@dcc.unicamp.br>
   Date: 10 Nov 1997 16:12:22 -0200

   If the shared libg++ directory is appended at the end of the library
   search path, it will only be used if a library cannot be found in any
   previous directory.  Thus, since that is the last directory in the
   search path, and the library has not been found in any other
   directory, we have two possible scenarios:

   1) the needed library *is* in the libstdc++ directory, so the
   directory should be looked at anyway.

   2) the needed library *is not* in the libstdc++ directory, so it is
   unavailable.  Even if the directory were a NFS-mount from a host that
   is down, the program would not be able to run.

You can't append a directory to the end of the shared library search
path.  The -R option prepends the directory to the start of the search
path.

You didn't consider the case where libstdc++ is not shared at all, or
where the program does not use it.

   IMHO, the most common situation is building a program a trying to run
   it, and not having an NFS-server down.

Certainly.  The problem arises when you link all your programs such
that they have an NFS directory on the search path, and the server
goes down, and suddenly you can't run any of your programs.  This
isn't a theoretical problem on SunOS; I've seen it happen to system
programs which people rebuild with gcc, like sendmail.

It would be possible to do something clever in collect2, like doing
the library searching there, and automatically adding the -R option if
the linker is going to wind up using a shared library.

Individuals can solve this problem by using -R options when they link,
or by setting the LD_RUN_PATH environment variable when linking to the
directories they want searched at run time, or by setting the
LD_LIBRARY_PATH environment variable when actually running the
program.

Ian