[plt-scheme] PLT Scheme linux distribution

Matthew Flatt wrote:
> At Tue, 26 Jun 2007 17:02:55 -0400, Eli Barzilay wrote:
>   
>> On Jun 26, Keith Frost wrote:
>>     
>>> Currently, in order to get a working PLT scheme installation, I do
>>> cd plt-370/src
>>> ./configure --prefix=/usr/local/plt
>>> make
>>> sudo make install
>>>
>>> If I now copy /usr/local/plt from one RHEL3 linux box to
>>> /usr/local/plt on another one, everything works fine.  If, however, I
>>> copy to /home/foo/bar on the other box, and then try to run
>>> /home/foo/bar/bin/mzscheme, I get
>>>
>>> /usr/local/foo/bin/mzscheme: error while loading shared libraries:
>>> libmzscheme3m-370.so: cannot open shared object file: No such file or
>>> directory
>>>
>>> Is this to be expected?
>>>       
>> Yes.
>>     
>
> Assuming that you used --enable-shared. Otherwise, there shouldn't
> be a shared library.
>
>   
>>> How hard would it be to remove absolute library paths from the
>>> installation, so that the executable looks up a relative (to itself)
>>> path to the associated library?
>>>       
>> Don't use eth `--prefix' flag, and the result will be in the same
>> directory, which you will be able to move anywhere you want.
>> ALternatively, use `--enable-origtree', but I don't remember the
>> details about that one.
>>     
>
> Also, you'll have to stay away from --enable-shared to avoid the
> absolute path that is required in an executable to refer to the shared
> library. (As far as I know, here's no easy way in Linux to have a
> relative reference from an executable to a shared library.)
>
>   
i think i could be completely wrong but isnt the env variable 
"LD_LYBRARY_PATH" used to handle this on linux env?
> Matthew
>
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>   
LD_LY