The Crystal Programming Language Forum

Distribute statically linked compiler binary

I believe we should be distributing the compiler from the x86_64-linux-musl target, or at least produce a release artefact from this target.

My apologies if I missed something in the distribution scripts etc, I’m not 100% read up on that side of the codebase.

would make things a whole lot more portable

I don’t follow. The compiler executable in our distribution packages is statically linked.

ldd /usr/lib/crystal/bin/crystal
        statically linked

It’s built exactly as you describe it: distribution-scripts/Dockerfile at master · crystal-lang/distribution-scripts · GitHub

I believe the networking is reliant on glibc being present, despite the binary being statically linked.

What leads you to assume this? Can you point out any misbehaviour?

Building static binaries with the compiler compiled with glibc produces issues like this one static build with openssl causes segv · Issue #3182 · crystal-lang/crystal · GitHub

I essentially want to bump this Promote x86_64-linux-musl to tier 1 platform · Issue #8732 · crystal-lang/crystal · GitHub
I’m very happy to offer help, I just need a pointer in the right direction to make the changes.

That’s a really old issue. Can you show a recent example of an error you encountered?

Otherwise, I don’t think there’s really any blocker for promoting x86_64-linux-musl to tier 1. There is essentially no practical effect either, though. So I’m wondering what’s your motivation to push that?

It’s a bit of a niche issue, but would be resolved by distributing a musl binary.

The problem specifically is that I want to pull in different versions of the compiler on an alpine system, with which I wish to compile static binaries.
Currently, the only option for doing the above is via the glibc binaries, which don’t support static compilation nor do they work on alpine.
I could build, store, and fetch the different versions of the compiler myself, but seeing as there was an issue to start doing exactly that, I thought I’d push/help the existing issue.

As I said, happy to do the work if someone points me in the right direction.

In terms of output, I was getting identical output as this issue static build with openssl causes segv · Issue #3182 · crystal-lang/crystal · GitHub

# docker run --rm -it alpine:3.14
apk add gcc libevent-static musl-dev pcre-dev gc-dev file
wget -O- | tar -xz
cd crystal-1.0.0-1
rm lib/crystal/lib/libgc.a
echo 'puts "Hello World"' >
bin/crystal build --static
file test


test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped

The only difference to linking against glibc is that you need to remove the bundled libgc (rm lib/crystal/lib/libgc.a) because that expects to link against glibc.