Hello Jason,
On Fri, Jun 28, 2019 at 5:20 PM Jason McBrayer jmcbray@carcosa.net wrote:
I've written a small application that uses osicat for finding file permissions and distinguishing files from directories. It has an asdf system definition, and I load it with ql:quickload.I've packaged it into a single executable using asdf:make, and it works fine, as long as I'm running it as the user I built it as. Running as another user, it errors out on not being able to load a shared library somewhere in my .cache directory; I guess this is what osicat compiled when I did (ql:quickload :osicat).
My question is, how can I make this application available to other users on my system? I've tried putting the shared library in /usr/local/lib64 and running ldconfig, but the application still looks for it in its original location.
I'm sorry I don't have a concrete recipe as I've never done this sort of deployment with SBCL, but you have (at least) two options:
1. Use ASDF's static-image-op, which can statically link osicat's helper library into the SBCL executable.
2. Close the helper library before producing the executable (e.g., via sb-ext:*save-hooks*) then reopen it when the executable is launched (e.g., via sb-ext:*init-hooks*).
SBCL actually does (2) automatically and the problem is probably that CFFI is loading the helper library using its full path. If the helper library had been loaded by name instead, SBCL would have been able to reload it properly. When a library is loaded by name, it'll be searched in the usual places you were expecting. CFFI sort of tries to do avoid loading by full path[1], but it's probably not succeeding. If you add that directory within .cache where libosicat.so lives to LD_LIBRARY_PATH (or similar) before compiling your application, CFFI might be able to load the library by name and this might solve your problem.
HTH,