[Openmcl-devel] CCL startup script (ccl & ccl64) is not Bourne Shell compatible
tfb at tfeb.org
Sun Oct 18 06:19:14 EDT 2009
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
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.
> 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
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.
More information about the Openmcl-devel