On Wed, Sep 15, 2010 at 11:19:16AM +0300, Nikodemus Siivola wrote:
> On 15 September 2010 06:11, Peter Keller <psilord@...> wrote:
> > How can I find the absolute paths of all the loaded shared libraries
> > in a running lisp image? I'm writing an application which, before it
> > calls save-lisp-and-die, needs to copy all loaded shared libraries to
> > the current working directory of the lisp image. This is so the shared
> > objects it needs can be moved along with the executable to another
> > machine for execution. A constraint is that I'm not going to know a
> > priori the set of loaded shared objects until just before I call
> > save-lisp-and-die and those libraries may have been loaded via cffi
> > or some other means.
> This is going to be ugly, and is technically unsupported right now.
> Sorry about that.
Thank you for the help! I appreciate it very much. The purpose of my
query is that I've written a master/slave library meant for distributed
computing and I want to make the production of the application binary
(and associated libraries) as simple and complete as possible for the
> To get the actual absolute pathname of the .so you have to duplicate
> the searching behaviour of dlopen(), which is somewhat platform
> dependent, and also depends on the current working directory at the
> time the library was loaded.
> For 90% of cases just searching LD_LIBRARY_PATH likely sufficient and
> correct -- if that works for your case, good. If not, read the dlopen
> docs carefully, and see what other environment variables or hardcoded
> locations are involved.
This is the hard part if only because there isn't a premade library
to parse ELF executables and I'd have to use (which I presume exists
though I don't see it in the SBCL manual) a native interface for reading
environment variables in SBCL.
I could write enough of an ELF file format parser to get what I need
out of the SBCL executable itself. I'm not too worried about that. The
ELF portion I really have to pay attention to is DT_RPATH, since that is
a pretty commonly used feature.
Hmm... loading the /etc/ld.so.cache file would probably go pretty far in
giving me the information I need concerning mapping bare library names
to pathnames. I will explore this one first since it seems so promising.
Google seems strangely silent on the file format for that file....
> If you find you have something loaded using current working directory,
> you're really out of luck right now -- either you have to alter SBCL
> to save the that information when the .so is loaded, or perhaps
> preferably, alter the code that does so to do something else (eg. use
> an absolute path.)
I'm going to bail on this problem since it doesn't come up that much in
practice. Once the executable has been saved, it is very unlikely in my
use cases that save-lisp-and-die will be called in the binary.
> Something like this, (untested):
> (defun fix-shared-object (obj new-pathname)
> (declare (pathname new-pathname))
> (setf (sb-alien::shared-object-pathname obj) new-pathname)
> (setf (sb-alien::shared-object-namestring obj)
> (native-namestring (translate-logical-pathname new-pathname)
> :as-file t))
I was doing something similar, but not as correct. :)