Shared library runpath trouble in Solaris.

Shared library runpath trouble in Solaris.

[Teemu Torma]

It seems that gcc does not specify any runpath for shared libraries.
At least if using multilibs the whole thing does not work, and
if `prefix' is not a standard one (I am using /usr/gnu), shared
libraries are not found at all.

I have made following changes to allow gcc automatically set -R
to all directories it adds itself.

Or am I missing something completely?

Teemu

1997-11-06  Teemu Torma  <tot@trema.com>

	* config/sparc/sol2.h: Define ADDITIONAL_LINKDIR_OPTION "-R".

	* gcc.c (do_spec_1): If ADDITIONAL_LINKDIR_OPTION is defined,
	add that option for each absolute link directories.

Index: gcc.c
===================================================================
RCS file: /trema/cvs/gnu/egcs/gcc/gcc.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -u -p -r1.1.1.1 -r1.2
--- gcc.c	1997/09/26 09:56:58	1.1.1.1
+++ gcc.c	1997/11/06 11:51:51	1.2
@@ -3226,6 +3226,19 @@ do_spec_1 (spec, inswitch, soft_matched_
 			      do_spec_1 (multilib_dir, 1, NULL_PTR);
 			      /* Make this a separate argument.  */
 			      do_spec_1 (" ", 0, NULL_PTR);
+
+#ifdef ADDITIONAL_LINKDIR_OPTION
+			      if (pl->prefix[0] == '/'
+				  || pl->prefix[0] == DIR_SEPARATOR)
+				{
+				  do_spec_1 (ADDITIONAL_LINKDIR_OPTION,
+					     0, NULL_PTR);
+				  do_spec_1 (buffer, 1, NULL_PTR);
+				  do_spec_1 (multilib_dir, 1, NULL_PTR);
+				  /* Make this a separate argument.  */
+				  do_spec_1 (" ", 0, NULL_PTR);
+				}			      
+#endif
 			    }
 			}
 		      if (!pl->require_machine_suffix)
@@ -3240,6 +3253,19 @@ do_spec_1 (spec, inswitch, soft_matched_
 			      do_spec_1 (multilib_dir, 1, NULL_PTR);
 			      /* Make this a separate argument.  */
 			      do_spec_1 (" ", 0, NULL_PTR);
+
+#ifdef ADDITIONAL_LINKDIR_OPTION
+			      if (pl->prefix[0] == '/'
+				  || pl->prefix[0] == DIR_SEPARATOR)
+				{
+				  do_spec_1 (ADDITIONAL_LINKDIR_OPTION,
+					     0, NULL_PTR);
+				  do_spec_1 (pl->prefix, 1, NULL_PTR);
+				  do_spec_1 (multilib_dir, 1, NULL_PTR);
+				  /* Make this a separate argument.  */
+				  do_spec_1 (" ", 0, NULL_PTR);
+				}
+#endif
 			    }
 			}
 		    }
@@ -3264,6 +3290,19 @@ do_spec_1 (spec, inswitch, soft_matched_
 			  do_spec_1 (buffer, 1, NULL_PTR);
 			  /* Make this a separate argument.  */
 			  do_spec_1 (" ", 0, NULL_PTR);
+
+#ifdef ADDITIONAL_LINKDIR_OPTION
+			  if (pl->prefix[0] == '/'
+			      || pl->prefix[0] == DIR_SEPARATOR)
+			    {
+			      do_spec_1 (ADDITIONAL_LINKDIR_OPTION,
+					 0, NULL_PTR);
+			      do_spec_1 (pl->prefix, 1, NULL_PTR);
+			      do_spec_1 (buffer, 1, NULL_PTR);
+			      /* Make this a separate argument.  */
+			      do_spec_1 (" ", 0, NULL_PTR);
+			    }
+#endif
 			}
 		    }
 		  if (!pl->require_machine_suffix)
@@ -3286,6 +3325,18 @@ do_spec_1 (spec, inswitch, soft_matched_
 			  do_spec_1 (buffer, 1, NULL_PTR);
 			  /* Make this a separate argument.  */
 			  do_spec_1 (" ", 0, NULL_PTR);
+
+#ifdef ADDITIONAL_LINKDIR_OPTION
+			  if (pl->prefix[0] == '/'
+			      || pl->prefix[0] == DIR_SEPARATOR)
+			    {
+			      do_spec_1 (ADDITIONAL_LINKDIR_OPTION,
+					 0, NULL_PTR);
+			      do_spec_1 (buffer, 1, NULL_PTR);
+			      /* Make this a separate argument.  */
+			      do_spec_1 (" ", 0, NULL_PTR);
+			    }
+#endif
 			}
 		    }
 		}
Index: config/sparc/sol2.h
===================================================================
RCS file: /trema/cvs/gnu/egcs/gcc/config/sparc/sol2.h,v
retrieving revision 1.1.1.2
retrieving revision 1.6
diff -u -u -p -r1.1.1.2 -r1.6
--- sol2.h	1997/10/24 09:12:33	1.1.1.2
+++ sol2.h	1997/11/10 12:11:04	1.6
@@ -157,6 +164,10 @@ Boston, MA 02111-1307, USA.  */
        %{pg:-Y P,/usr/ccs/lib/libp:/usr/lib/libp:/usr/ccs/lib:/usr/lib} \
        %{!p:%{!pg:-Y P,/usr/ccs/lib:/usr/lib}}}} \
    %{Qy:} %{!Qn:-Qy}"
+
+/* Add -R for each automatically included -L. */
+#undef ADDITIONAL_LINKDIR_OPTION
+#define ADDITIONAL_LINKDIR_OPTION "-R"
 
 /* This defines which switch letters take arguments.
    It is as in svr4.h but with -R added.  */

Re: Shared library runpath trouble in Solaris.

[Ian Lance Taylor]

   From: Teemu Torma <tot@trema.com>
   Date: Mon, 10 Nov 1997 15:04:45 +0100

   It seems that gcc does not specify any runpath for shared libraries.
   At least if using multilibs the whole thing does not work, and
   if `prefix' is not a standard one (I am using /usr/gnu), shared
   libraries are not found at all.

   I have made following changes to allow gcc automatically set -R
   to all directories it adds itself.

   Or am I missing something completely?

This is not a good idea, and, nothing personal, but I've explained why
so many times that I weary of doing it again.  Perhaps we need a
developers FAQ to answer this.  The short version is that if you
always pass a -R option to the linker, then your programs become
dependent on directories which may be NFS mounted, and programs may
hang unnecessarily when an NFS server goes down.  SunOS effectively
always passed a -R option for every -L option; this was a bad idea,
and so it was removed for Solaris.  We should not recreate it.

I agree that there is a problem here, and I agree that it would be
nice to fix it, but I do not think that this is the fix.  This can be
fixed in the linker, but I do not know how to fix it in the compiler.

Ian

Shared library runpath trouble in Solaris.

[Teemu Torma]

    From:  Ian Lance Taylor <ian@cygnus.com>
    Date:  Mon, 10 Nov 1997 11:42:33 -0500

    This is not a good idea, and, nothing personal, but I've explained why
    so many times that I weary of doing it again.  Perhaps we need a
    developers FAQ to answer this.  The short version is that if you
    always pass a -R option to the linker, then your programs become
    dependent on directories which may be NFS mounted, and programs may
    hang unnecessarily when an NFS server goes down.  SunOS effectively
    always passed a -R option for every -L option; this was a bad idea,
    and so it was removed for Solaris.  We should not recreate it.

This is not exactly same what SunOS does, here we add -R for each
compiler generated path, excluding relative ones (-B../ for example). 
I think this is part of the compiler infrastructure.  
Anyway, I agree that this creates unnecessary lookups.

The problem is mainly g++ problem.  If the compiler is installed over NFS,
stdc++ library has to be present anyway, and if multilibs are used,
just copying it into /usr/lib does not work.
    
    I agree that there is a problem here, and I agree that it would be
    nice to fix it, but I do not think that this is the fix.  This can be
    fixed in the linker, but I do not know how to fix it in the compiler.

I'd say it is essential to fix it.  And the linker can not be fixed
to undo NFS mounts, only to optimize unused directories away, as far
as I can see it.

Re: Shared library runpath trouble in Solaris.

[Ian Lance Taylor]

   From: Teemu Torma <tot@Trema.COM>
   Date: Mon, 10 Nov 1997 18:04:19 +0100

   I'd say it is essential to fix it.  And the linker can not be fixed
   to undo NFS mounts, only to optimize unused directories away, as far
   as I can see it.

Optimizing away unused directories is essential.  Your patch would
impose the directory requirements on all C programs, which presumably
do not use the shared libstdc++ anyhow.  It would also impose the
directory requirements even on people who do not have a shared
libstdc++.

The problem is not programs that do require the directories; those
programs are going to hang no matter what you do.  The problem is
programs that do not require the directories.

Ian

Re: Shared library runpath trouble in Solaris.

[Alexandre Oliva]

Ian Lance Taylor writes:

> Optimizing away unused directories is essential.  Your patch would
> impose the directory requirements on all C programs, which presumably
> do not use the shared libstdc++ anyhow.

Not if it only applies to C++ programs.

> It would also impose the directory requirements even on people who
> do not have a shared libstdc++.

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.

I vote for adding the directory that contains libstdc++ at the end of
the library run path, otherwise most people just won't use a shared
libstdc++, and will blame g++/egcs for created huge binary programs,
or will try to use a shared libstdc++ and blame g++/egcs for not being
able to find the library at runtime unless a special flag is given.

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

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Shared library runpath trouble in Solaris.

[Ian Lance Taylor]

   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

Re: Shared library runpath trouble in Solaris.

[Alexandre Oliva]

Ian Lance Taylor writes:

> 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

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

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

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

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

This should only be done for libstdc++, otherwise libtool would
break.

> 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 :-)

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: 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

Re: Shared library runpath trouble in Solaris.

[Alexandre Oliva]

[I've just re-read this message, before posting, and found that some
parts of it may be interpreted as aggresive or such.  Please consider
my lack of proficiency in English as the cause for that.]

Ian Lance Taylor writes:

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

> Actually, it seems to me that if the user uses any -R options, g++
> should not insert any.  Trust the user.

Although I usually agree with this, I'd rather disagree with this as
the default behavior of g++.  A C++ compiler is required to provide a
certain standard library, and requiring a user to add special
arguments to find that library is no good, IMHO.  Besides, removing
the standard library from the search path just because a -R option was
added would cause even more confusion.  I'd agree about removing it if
-nostdlib were issued, though.

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

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

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

Are we talking about portability or what?  I've got a hard time
figuring out exactly which variables I had to set to get g++/egcs++
*tests* running correctly on the *four* platforms I regularly test,
(Sparc Solaris 2.5, SunOS 4.1.3, IRIX 5.2 and pc Linux).  And I
consider myself a rather experienced Unix hacker, now think about
users that try to run their C++ compilers and write to me saying it
doesn't work, or, even worse, post a message to bug-g++.

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?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Shared library runpath trouble in Solaris.

[Ian Lance Taylor]

   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

Re: Shared library runpath trouble in Solaris.

[Alexandre Oliva]

Ian Lance Taylor writes:

> Note that if we always use a -R /usr/lib option, it will break certain
> uses of LD_LIBRARY_PATH.

Now this is a very good reason for not adding -R arguments.

So, it seems to me that the only remaining alternative is to hardcode
the full pathname of the library in the library itself.  So, if one
does not use a shared libstdc++, this is not an issue.  If one uses,
the library will know how to find itself.  I know this makes it
impossible to move the library to another directory, but there's no
such thing as a free lunch, after all.

Unfortunately, AFAIK, hardcoding library paths is not that portable,
and libtool has a lot of work trying to make this all transparent to
users.  Maybe we should borrow some shared-library knowledge from
libtool...

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

There's a problem when you're linking a program linked against a
shared library that was not installed yet.  If gcc automatically
hardcodes the library path where the library is sitting, it won't be
able to find it at run-time.

IMO, gcc should only take care of libstdc++ by itself if linking is
performed with g++ and -nostdlib is not issued.  Otherwise, let the
user take care of that by himself.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Shared library runpath trouble in Solaris.

[Alexandre Oliva]

Alexandre Oliva writes:

> There's a problem when you're linking a program linked against a
> shared library that was not installed yet.  If gcc automatically
> hardcodes the library path where the library is sitting, it won't be
> able to find it at run-time.

By the way, there's a problem in collect2 regarding this situation, on
SunOS 4.1.3

collect2 will mimic run-time library search when it is looking for
dynamic library dependencies of a program.  However, when the library
is stored in one directory and will be installed in another, collect2
won't find it.

Given that libfoo.so.1.0 is in .libs, and it will be installed in
/usr/foo/lib, if I try:

% egcs foo.o -Wl,-rpath,/usr/foo/lib -L.libs -lfoo
collect2: dynamic dependency libfoo.so.1.0 not found

I must set LD_LIBRARY_PATH=.libs in order to get this correctly
linked.  IMO, collect2 should look for libraries in directories
specified with -L, not with -R.  Does anyone disagree?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Shared library runpath trouble in Solaris.

[Teemu Torma]

    From:  Ian Lance Taylor <ian@cygnus.com>
    Date:  Tue, 11 Nov 1997 12:10:36 -0500

    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).
    
I think this has to apply only to compiler generated search paths,
not to user specified ones.  

Maybe options -nostdrunpath to disable this feature and -allstdrunpath
to do it always regardless whether a library is found or not.  I can
see potential use that the run path is always there, in the case that
some library has to be replaced with os-specific/gcc-specific one.

Teemu

Re: Shared library runpath trouble in Solaris.

[Swen Thuemmler]

On 11 Nov 1997, Alexandre Oliva wrote:

> So g++ should invoke the linker like this:
> 
> ld -R/path/to/libstdc++ -R/usr/lib -R/whatever/-R/flags/issued/by/the/user

But it should only do this, when LD_RUN_PATH is not set, since
unfortunately -R cancels the settings from LD_RUN_PATH. So when
LD_RUN_PATH is set (and -R is not present) /path/to/libstdc++ should be
added to LD_RUN_PATH. 

I think it should be the default. When I installed the shared libg++, I
got a lot of complaints from our users asking why their programs did no
longer run. The tenor was, that for getting an executable it should be
sufficient to say "c++ -o program part1.cc part2.cc ... partx.cc" like god
has it intended to be :-), without the requirement for funny options
nobody ever heard of. Eventually I made a little shellscript and called it
g++, which adds /usr/local/gnu/lib to LD_RUN_PATH if it is set or else
adds -R /usr/local/gnu/lib and then calls g++.real. But it would be great
when g++ could handle it per default (and perhaps configurable via
specs...)

Just my 2 cents

--Swen

Re: Shared library runpath trouble in Solaris.

[Jeffrey A Law]

  In message < 199711101642.LAA15048@subrogation.cygnus.com >you write:
  > This is not a good idea, and, nothing personal, but I've explained why
  > so many times that I weary of doing it again.  Perhaps we need a
  > developers FAQ to answer this.
Agreed.  I've added it to my prototype FAQ; I just need to get it
up on the web site for folks to use.

jeff