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

[Aleksej Saushev]

Tim Bradshaw <tfb at tfeb.org> writes:

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

Well... If you don't know your target system, you may be unpleasantly
surprised at some point. That's with usage of both "#!/usr/bin/env" and
LD_LIBRARY_PATH.

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

I use FreeBSD at work, and I have "make" in /usr/bin (system one) and in
~/bin (wrapper around NetBSD make), they are slightly incompatible,
I also have NetBSD make in /usr/pkg/bin and ~/pkg/bin, they don't have
the same configuration, they use different make scripts from different
places. If they'd rely on environment, it would be less convenient in
use and could lead to mistakes.

Things are worse on my home system, where I have "mpd" in different
places and those are "music playing daemon" and "message passing daemon"
from MPICH. That is they differ even more than you can expect.

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

The main difference from Lisp is that you (as a sysadmin) have control on
both interpreter and RPATH, you can change them in-place (except in some
extremely paranoid cases, where you run security-hardened site with
executable protection and such).


-- 
HE CE3OH...