Hi, I'm new to the list and fairly new to common-lisp. I have a question that is not actually 100% specific to osicat, probably, but I don't know where to ask, and osicat was where I ran into the problem. My apologies if this is off topic or otherwise inappropriate.
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.
For reference, I am using SBCL 1.4.14 on 64-bit Fedora Linux.
-- +----------------------------------------------------------------------+ | Jason F. McBrayer jmcbray@carcosa.net | | The scalloped tatters of the King in Yellow must hide Yhtill forever.|
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,
Luís Oliveira writes:
- Use ASDF's static-image-op, which can statically link osicat's
helper library into the SBCL executable.
Thanks! I didn't know about this, and this would have been my preferred choice. Unfortunately, my distribution's SBCL is not built with support for linkable runtime. Oh well.
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.
This worked. Thank you very much.
-- Jason McBrayer | “Strange is the night where black stars rise, jmcbray@carcosa.net | and strange moons circle through the skies, | but stranger still is lost Carcosa.” | ― Robert W. Chambers,The King in Yellow
-
Jason McBrayer -
Luís Oliveira