Ah ha!! Thanks much for the additional info, Ara.

Your 5 May 2004 writeup was particularly good:
 >
 > You have two good choices
 >
 >  a) install ruby where your system looks for stuff
 >
 >  b) configure your system to look where ruby puts stuff
 >
 > Having LD_RUN_PATH set at compile time encodes it
 > in the binaries. It sets up all the bins and libs so
 > they know where to look for things.


You also give a good diagnostic tool:
 >
 > In general, if you are having load errors do this
 >
 > ruby -e 'p $LOAD_PATH'
 >
 > this tells you where ruby looks for things.


In your 32 Mar 2006 msg, you gave a really nice recipe:
 >
 > If you follow these steps just about anything will work:
 >
 >    - chose a common nfs location.  we'll call it /nfs
 >
 >    - every single time you compile something do this
 >
 >        export LD_RUN_PATH=/nfs/lib
 >        export LD_LIBRARY_PATH=/nfs/lib
 >        ./configure --prefix=/nfs && make && make install
 >
 > I set LD_LIBRARY_PATH and LD_RUN_PATH in my .bashrc
 > because i do this so much.  the cool thing with
 > LD_RUN_PATH is that it encodes inter-library dependencies
 > (so ruby tk.so needs libtk.so needs ...) , so users don't
 > have to set LD_LIBRARY_PATH themselves...They just have to
 > add /nfs/bin to their path.


So it appears that:

   LD_RUN_PATH
      tells the binaries where to look for things
      when they're running

   LD_LIBRARY_PATH
      tells the linker where to look for things
      when it is creating the binaries

The installation sequence for a non-standard location 
Solaris location therefore turns out to be:

# Clear out a previous build & create config.h
make distclean
./configure --prefix=/wherever/you/want

# Set the values you need when compiling
sh:   export LD_RUN_PATH=/wherever/you/want/lib/
       export LD_LIBRARY_PATH=/wherever/you/want/lib/

csh:  setenv LD_RUN_PATH /wherever/you/want/lib/
       setenv LD_LIBRARY_PATH /wherever/you/want/lib/

# Compile without installing, then install binaries & docs 

make
make install-all

Thanks again. Considering that your original post on this
subject was in 2004, I can see why your responses have
become shorter!

I greatly appreciate your help, and am glad to say that
I now have functional installation of Ruby.

P.S.
I'll be happy to put this information on a Wiki page
somewhere. I went to RubyGarden, but only saw a small
comment box. I could stuff it in there, post at my
weblog, or put it anywhere else that will let the
community find it easily. Suggestions?


ara.t.howard / noaa.gov wrote:
> On Fri, 19 May 2006, Eric Armstrong wrote:
> 
>> That's a good process that will probably work
>> decently. But then Ara Howard added this cryptic
>> note:
>>>
>>> don't forget to do both of these before compiling
>>>
>>>  LD_LIBRARY_PATH=/wherever/you/want/lib
>>>  LD_RUN_PATH=/wherever/you/want/lib   # most important!
>>>
>>> if you do this all the stuff you compile it will
>>> inter-operate nicely--e.g. ruby extensions--and other
>>> users will be able to use it without having their
>>> LD_LIBRARY_PATH set. They'll only require PATH.
>>>
>> I sure this makes sense, but I'm missing the mental
>> model--the picture of what's happening--that would
>> explain /why/ it makes sense. These variables aren't
>> mentioned in the Makefile, so they must be important
>> to gcc. But why, if I'm /creating/ the lib as part
>> of the process??
> 
> it has nothing to do with ruby, the Makefile, or gcc - it's all about your
> linker:
> 
> man ld.so
> man ld
> http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/615935bf1489d843/dae3f2dd2fae3e1e?q=LD_RUN_PATH&rnum=6#dae3f2dd2fae3e1e 
> 
> http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/b0ecc81f80082df8/f651b1d2000dd5e1?q=LD_RUN_PATH&rnum=7#f651b1d2000dd5e1 
> 
> http://www.visi.com/~barr/ldpath.html
> 
> 
> let me know if this doesn't shed some light.
> 
> regards.
> 
> 
> -a