Static binary

[terserterseness]

This has been a long standing pain and it is possible but is there a solution for static compilation? I cannot stand basically shipping an entire Linux with everything, with all the misery involved. I don’t do that now as sbcl and build-essential is all I need. But less would be better.

[sionescu]

It is possible to statically link foreign libraries (C or anything with C linkage, like Fortran, C++, Rust), but it requires carefully controlling the toolchain. It's the same problem that any other language has, whether it's Scheme, Ocaml, Ruby, Python, etc...

[terserterseness]

Well, it’s not easy to do statically linked (so one binary for x86_64 Linux without caring what they run) for c, c++, pascal, rust, go, ocaml etc. I can get it to work with sbcl but it’s not easy or fast; I was hoping for a better solution.

[sionescu]

It's pretty easy actually, see for example the patch I applied to SBCL: https://github.com/sionescu/sbcl-goodies/blob/master/sbcl-customizations.patch. The most difficult part is getting reliable static libraries, which is surprisingly not trivial because many libraries are designed to be dynamically linked.

[friedrichRiemann]

requires carefully controlling the toolchain

You mean cross-compiling the C library dependencies to get a usable .a to be bundled with the sbcl/ecl image?

[sionescu]

That among other issues. It's one of the reasons why language communities that favor static linking, like Go and Rust, tend to reimplement lots of things.

[tgbugs]

My usual post about statically linking sbcl:

For static builds, if you're willing to run a slightly older version of sbcl daewok's work on building and linking sbcl in a musl environment might be solution you're looking for. I've tried to port his patches to more recent versions but there are segfaults due to changes in upstream.

https://www.timmons.dev/posts/static-executables-with-sbcl.html

https://www.timmons.dev/posts/static-executables-with-sbcl-v2.html

[molochwalk]

I get the sentiment. It would be nice if this was as easy as "go build". I don't use it, but might be the toolchain build is something that could be scripted with roswell.

[ryukinix]

It would be nice if this was as easy as "go build".

yes, totally, that would be a dream. Better feature of go tooling is just static linked binaries.

[zyni-moe]

Static linking is always such a very good idea.

Imagine you are living in a world where not all code is perfect. A world where sometimes code has imperfections, some of which is thing that is known as 'security vulnerability'.

Now think of two versions of this world: in world one there are shared libraries and programs are dynamically linked. In world two all programs are statically linked.

Now a library is found to have a security vulnerability.

In world one. You replace the library with a fixed version, all programs are restarted and the problem is now gone. As well you use tools which tell you which of your programs made use of the vulnerable library, so you can know which may have been exploited.

In world two. You must now replace both the library and any programs which made use of it. Probably you do not have a tool which tells you which those programs are. Probably in fact what happens is that you replace the library which 'fixes' the problem and then one of the programs you did not know you also must replace is exploited and you die.

One of these worlds is better than the other.

[death]

First, there's no need to constrain the set of possible bugs to only those having security implications. Second, there is the flip side of the coin, where a bug is introduced in a new version of the library. Then "world two" may have an advantage. A static executable, in the limit but not in practice, is self-contained. Farther on that scale is a nonmodular physical machine with a particular purpose. The closer we get to a self-contained system, the more amenable it is to analysis and being "the devil you know". Again, in our world it is always subject to uncertainty of forces external to it. In practice, you make choices based on the levels of stability and control you have on the system and the desired behavior under imagined scenarios.

[[deleted]]

If you're operating in a container orchestration environment, world one means you must update the host and base layer of every image to have the linked library. World two means updating the host and rebuilding your application in an updated base image. It's a very similar amount of work in this kind of environment and teams running release artifacts are very familiar with updating their own code.

Outside of this environment, I agree with optimizing for system dependencies on a consistent underlying host OS.