2 ms·
Doesn't `(save-lisp-and-die :executable t)` [1] create static binaries? I had a look at one of my SBCL-made binaries on MacOS, it shows this: ▶ otool -L
by brabel 5y ago
Doesn't `(save-lisp-and-die :executable t)` [1] create static binaries?
I had a look at one of my SBCL-made binaries on MacOS, it shows this:
▶ otool -L lisp-enc
lisp-enc:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
EDIT: GraalVM takes several minutes to generate binaries, and the binary may not behave the same as the JVM-based runtime, so I wouldn't recommend using that.
[1] http://www.sbcl.org/manual/#Function-sb_002dext-save_002dlisp_002dand_002ddie http://www.sbcl.org/manual/#Function-sb_002dext-save_002dlis...
- svetlyak40wt 5y agoYeah, you've got a dynamically linked binary. There is a work in progress on SBCL to make it possible to create a really static binaries: https://www.timmons.dev/posts/static-executables-with-sbcl-v2.html https://www.timmons.dev/posts/static-executables-with-sbcl-v... I tried this fork and it worked for me!
- p_l 5y agoWell, the example was on OSX, and it's generally not a good idea to do static linking there ;) (same on many other systems, you need minimally certain amount of dynamically linked stuff). Blaze/Bazel rules for Lisp support building fully static SBCL binaries (except possibly for grabbing dynamic stuff that is forced by glibc). ECL also supports static linking.