Shared library runpath trouble in Solaris.

[Ian Lance Taylor]

   From: Alexandre Oliva <oliva@dcc.unicamp.br>
   Date: 11 Nov 1997 00:36:33 -0200

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

   So g++ should invoke the linker like this:

   ld -R/path/to/libstdc++ -R/usr/lib -R/whatever/-R/flags/issued/by/the/user

It seems to me that the user's -R options should go first.  Actually,
it seems to me that if the user uses any -R options, g++ should not
insert any.  Trust the user.

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

   I did, and I haven't noticed yet why it would break.

Perhaps I misunderstand, but it seems to me that it would break for
the same reason we've been discussing: the program would have a -R
option it does not need.  That's the bad situation I want to avoid:
the compiler should never silently insert a unnecessary -R option.

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

   Only if the libstdc++ directory is searched before others.

It depends upon how the dynamic linker works.  I don't know how they
work.  I guess this should be tested on a few platforms.

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

   Which is as portable as, say, ActiveX :-)

It's portable to any SVR4, Solaris, or Linux system, and to any system
which uses the GNU linker.

Ian