[Openmcl-devel] CCL startup script (ccl & ccl64) is not Bourne Shell compatible

[Tim Bradshaw]

On 18 Oct 2009, at 05:20, Ron Garret wrote:

> You know the system configuration *at build time*.

If only that were true!  You may be lucky and have a system which  
*has* a standard location for the things you need, but often you don't  
have that luxury.  Where is the standard location for Perl on Solaris  
2.6?  Where's the standard location of Oracle on anything, or for that  
matter CCL?

That's why you must choose, at the earliest, at install time.

Actually, CCL is a good example.  Let's say I want to distribute some  
application which uses CCL.  Where is it, actually?  I'm using a  
fairly common platform (OS X) at home, and it's, um /Local/Ephemeral/ 
tfb/packages/i386/ccl/default.  You're not going to be able to wire  
that in at build time.

> There's no
> guarantee that the configuration won't change after that.  All else
> being equal, it is better to be able to make changes without having to
> rebuild everything in order to make it work again.

Indeed, one of the main things I have to deal with is where there are  
multiple different versions of things, and where the version I need to  
use is not the platform's one.  You can't replace the platform's one,  
because the platform will likely have dependencies on that version.   
So you need your own one, which by definition lives in some non- 
standard place.  And, of course, since you're dealing with developers,  
you'll suddenly discover that they now depend on some new release of  
the thing, but you still need to have other things run which work only  
with the older version.

[About LD_LIBRARY_PATH]

> Maybe I need to be enlightened.  What is this "correct way"?

LD_LIBRARY_PATH is probably the best of a bad lot, assuming you do not  
know at compile time where the libraries will be, which you generally  
do not. Some platforms have better approaches (LD_CONFIG / crle on  
Solaris). It's important to set LD_LIBRARY_PATH in wrappers, not  
globally though.

All of this comes down to a dynamic vs static decision.  I think as  
Lisp programmers we know which of these is best :-)

Damn, I said I would not follow up any more.  Sorry.

--tim