Re: Shared library runpath trouble in Solaris.

[Ian Lance Taylor <ian@cygnus.com>]

   From: Alexandre Oliva <oliva@dcc.unicamp.br>
   Date: 11 Nov 1997 01:52:56 -0200

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

   So it seemed to me, but you said -R would add a directory to the
   beginning of the search path...  If this is not correct, the reverse
   order should be used.

Sorry for the confusion.  The -R options are all concatenated together
in the order in which they appear.  They are then all searched.  Then
LD_LIBRARY_PATH is searched.  Then /usr/lib is searched.

Note that if we always use a -R /usr/lib option, it will break certain
uses of LD_LIBRARY_PATH.  I've used LD_LIBRARY_PATH to force programs
to use a shared library I had instrumented in some way.  If /usr/lib
is built into the program, there is no way to override that short of
using a special dynamic linker, or relinking the program which may be
difficult.

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

   So what?  If it doesn't ever search that directory, there's no problem
   at all.  So, if it is the last directory in the search path, there's
   no problem to solve: either the library will not be found at all, or
   it will be found in this last directory.  If the NFS-server for that
   directory is down, the program wouldn't be able to run anyway.

We need to test dynamic linkers to see how they behave.  I do not
trust all dynamic linkers to not look through directories they do not
need to look through.  There is also the -R vs. LD_LIBRARY_PATH
problem I mention above.

   > That's the bad situation I want to avoid:
   > the compiler should never silently insert a unnecessary -R option.

   I'd consider that a necessary -R option.  Consider what kind of damage
   it would cause to you if libgcc were shared, and try to understand my
   position as a C++ programmer.

I do understand the problem.  Honest.  However, if libstdc++ is not
shared, then it is an unnecessary -R option.  libstdc++ is not always
shared, and we should not assume that it is.  People may deliberately
choose to use a static libstdc++ to avoid shared library problems.
People may deliberately link with -Bstatic -lstdc++ -Bdynamic to avoid
shared library problems.  If we use -R, we force a particular instance
of shared library problems onto them even though they've tried to
avoid it.

   There are lots of questions like this in bug-g++, gnu.gcc.help.
   Several people have had trouble with that recently.  Wouldn't it be
   much better to make it work in the general case, and let people with
   special needs to fulfill them with extra switches?

Yes, of course.  I'm not arguing against that, (provided the extra
switches are natural and clear).

I'm just pointing out a serious problem I've seen with automatically
adding -R options.  I've even described a solution which could be
implemented in collect2.  What's wrong with the solution I described?
(To repeat: do the library searching in collect2, add a -R option if a
shared library will be used; I'm happy to make this a special case for
libstdc++, but I think it would also be reasonable to act otherwise).

Ian