Distribute statically linked compiler binary

Crystal Contrib
1

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.

2

would make things a whole lot more portable

3

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

4

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

5

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

6

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.

7

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?

8

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

9 
# docker run --rm -it alpine:3.14
apk add gcc libevent-static musl-dev pcre-dev gc-dev file
wget -O- https://github.com/crystal-lang/crystal/releases/download/1.0.0/crystal-1.0.0-1-linux-x86_64.tar.gz | tar -xz
cd crystal-1.0.0-1
rm lib/crystal/lib/libgc.a
echo 'puts "Hello World"' > test.cr
bin/crystal build --static test.cr
file test

Gives:

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.

2 Likes