Re: deploying CLG

"Walter C. Pelissero" <[email protected]> Fri, 14 Dec 2007 14:04:01 +0100
Newsgroups gmane.lisp.clg.devel
Message-ID <[email protected]>
Espen S Johnsen writes:
 > After having thought about this problem for a while and tried out a few
 > things, I have come to the conclusion that the best solution would
 > probably be to modify the initialization code in CMUCL (and SBCL).
 > 
 > The attached code will try to load a shared object from the library
 > search path before signaling an error, if loading from an absolute path
 > fails. When installing an clg application the shared object files could
 > be copied to a common directory and LD_LIBRARY_PATH set in a wrapper
 > script. To make this possible all the alien.so files are now given unique
 > names.
 > 
 > What does people think about this solution?

I haven't read the code, but I'd like to share a few thought from the
top of my mind.

Trying to load from the original absolute pathnames is a security risk
(although remote).  Example: I john@development compiled a program and
installed on every other Unix machines of the company.  A dodgy fella
john@support reads this mail message and realises we share an
identical home directory pathname.

I don't see when an absolute pathname could be useful beyond the
development phase.  Phase in which I personally never debug a dumped
image.

I believe dlopen is doing already a fine work.  I wouldn't replicate
it, even partially.

Yes, the disambiguation of the CLG shared objects can rid us of all
the absolute pathnames.

-- 
walter pelissero
http://www.pelissero.de

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace