Hacker News Reader

Comment by snake_case | Hacker News Reader

I tried out Crystal and Kemal a few months ago and really enjoyed it. However, one issue that's preventing me from wanting to take it to production is that apparently you cannot generate fat binaries and run them without Crystal also being installed in your deployed environment.

Is that true still? If it is, does anyone know when support for "real" fat binaries (no need for Crystal on the server) will be available?

View on HN

Crystal supports static linking with `--static`, unfortunately glibc and openssl don't like static linking, so it turns out to be easier to do in an alpine linux chroot/container/etc which uses musl instead of glibc. Crystal is in the alpine linux repositories as of 3.8, so this should be now a lot easier.

If someone wants to generate some good tooling around this workflow, it'd be greatly appreciated.

I wonder if it is possible to do something that staticly link everything except the few libraries that misbehave.

There isn't much else left to link - iirc openssl, glibc, libevent, libpcre are all it needs.

You can use my alpine docker image to statically compile without any fuss: https://hub.docker.com/r/durosoft/crystal-alpine/

I'll be updating it later today with 0.25.1 support.

You can statically compile a local crystal file using a docker one-liner that is included in the description.

That's great! I've only heard complaints that it's difficult to statically compile. Sounds like a solved problem though.

The docker approach is I think a well kept secret but I'm trying to get more people to realize it's a thing. My gcf.cr tool abstracts this away for you if you are deploying to a Google Cloud Function

Do you mean statically linked binaries? Fat binaries generally refer to multiple ABIs in the same image, a mostly Apple thing these days.

I'm referring to fat binaries like the one Golang would compile too. Apologies if I have some terms mixed up here!

Golang produces one single binary you can deploy to your target environment and doesn't really require anything else installed.

From what I've read, Crystal generates a binary but you also need to ensure Crystal is installed on your target environment.

Golang makes statically linked binaries. (Well, until you use cgo.)

By default, Crystal generates dynamically linked binaries. You absolutely do not need Crystal to run them. But you do need:

- Boehm GC (libgc-threaded)

- libevent

- PCRE if the program uses regexps

- libyaml if the program uses yaml

- OpenSSL if the program uses crypto/TLS (?)

Here's an example ldd output:

    /usr/local/bin/shards:
            libyaml-0.so.2 => /usr/local/lib/libyaml-0.so.2 (0x8c0bb1e000)
            libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x8c0bd3c000)
            libm.so.5 => /lib/libm.so.5 (0x8c0bfb8000)
            libgc-threaded.so.1 => /usr/local/lib/libgc-threaded.so.1 (0x8c0c1e6000)
            libthr.so.3 => /lib/libthr.so.3 (0x8c0c444000)
            libevent-2.1.so.6 => /usr/local/lib/libevent-2.1.so.6 (0x8c0c66c000)
            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8c0c8c3000)
            libc.so.7 => /lib/libc.so.7 (0x8c0cad2000)
            libdl.so.1 => /usr/lib/libdl.so.1 (0x8c0ce8f000)
            libcrypto.so.42 => /usr/local/lib/libcrypto.so (0x8c0d091000)

You can try `crystal build --static` though :)

Thanks for explaining! In other threads, I've seen people refer to them as fat binaries, but yes, I've also seen them referred to as statically linked binaries.

Not sure when/if this changed recently, but from:

https://crystal-lang.org/docs/using_the_compiler/ "Creating a standalone executable":

crystal build some_program.cr --release --static

Builds a static binary (just tried it on Ubuntu 18.04 with a simple hello-world).

Thanks! These instructions seem to have less warnings than I saw last time, which implies it's more stable now.

You're going to have much better luck with an alpine-based docker image. Unfortunately non-musl based systems have a lot of issues with static compilation, so while this will work with hello world, if you try something more complicated you will likely get linker errors.

Particular to the c library? Because an "ldd" on the hello world listed quite a few libs which all worked fine with a static build.

openssl and libz are particularly fussy

I could definitely see openssl being tricky (libz not so much, but I might very well be naive here) - but how does changing the libc help with either?

glibc has some plugins which make it not easy to statically link. Musl doesn't have that. And alpine compiles openssl etc. with a config amenable to static linking. It's all about distro choices.

Reply on news.ycombinator.com