freenode/#sbcl - IRC Chatlog
Search
13:03:32
jmercouris
when making an image with SBCL, is that image completely portable across any machine with the same SBCL/Lisp kernel?
13:12:31
flip214
you can't move between Debian and CentOS, for example, as the shared libraries are too different.
13:12:59
flip214
and if you use AVX2 in some way, then it might not run correctly on older CPUs, of course.
13:13:44
Shinmera
flip214: If you don't compile with core compression on there's no shared libraries that SBCL depends on.
13:15:11
scymtym
Shinmera: there is libc which can be an issue if you build on e.g. arch and then try to run on debian wheezy
13:17:15
Shinmera
flip214: User code can require on things specific to one particular machine anyway so that's outside the scope of the question regardless
14:21:38
jmercouris
arte there implementation differences in the lisp kernel for different linux distributions?
14:22:07
jmercouris
is there anything special I have to do outside of a traditinal asdf:make to achieve this?
14:24:26
jmercouris
I have a lisp system right, I compile it on System A into an executable and try to run it on System B
14:26:04
jmercouris
for example, does SBCL potentially hard-code the paths of shared libraries in an image?
14:26:25
jmercouris
System A and System B are two different machines, sorry I should have said "Computer A" and "Computer B"
14:27:15
jmercouris
"doesn't work" means that the Lisp executable, does not operate as it does when it is simply compiled on Computer B
14:28:09
jmercouris
The Lisp program is supposed to start a server for listening to commands (s-xml-rpc if you recall stassats), and that server appears to be non-operational in the first scenario, but operational when the system is compiled on Computer B
14:30:35
jmercouris
I will try to gather all relevant information and provide a report, if I can, if I don't come back, I've solved the problem :D
14:31:27
scymtym
summarizing the SBCL side: if SBCL is compiled on one systems, certain (weak in the sense of rarely violated) dependencies on the host system are baked into the sbcl executable (unless you specifically ask it to e.g. use certain processor features). if that sbcl is used to dump an executable, user code may introduce more dependencies on the system on which the compiling and dumping happens. typical examples include names of files or
14:35:03
scymtym
for things like filenames it depends on the user code. dumping a filename into an executable on one system and running that executable on a different system can lead to arbitrary behavior depending on what the code does with the filename
14:35:57
jmercouris
like for example, good luck distributing an image with QURI which depends on system paths...
14:36:35
scymtym
for example (defvar *config-file* (format nil "~A/config.sexp" (getenv "HOME"))) (defun main () … *config-file* …) is wrong
14:36:56
jmercouris
I use a deferred variable initializer or don't put things in top-level forms to avoid that
14:37:20
jmercouris
I have a macro for that, but I appreciate the suggestion anyway, as of course you didn't know I already knew that specifically
14:37:41
jmercouris
its interesting, because I can compile for macOS and distribute among other Macs no problem
14:41:30
mercourisj
and there's a problem with the guix pack as well: https://github.com/atlas-engineer/next/issues/160
14:42:03
mercourisj
the issues are related to not being able to find a binary, which is fine, you can symlink a folder to find the binary to launch it within the guix pack
14:42:57
mercourisj
I don't want to waste your time chasing this kind of stuff though, so I will come back when I have something more intelligent
14:43:33
mercourisj
first, fix the guix pack, then see why it might be that the lisp executable is not properly starting