Dockerfile.alpine-custom-rust

# Docker image used for experiments building our Rust code on a musl Linux
#
# This uses the edge Alpine image and both `rustc` and `cargo` from the Alpine package.
# Alpine ship patched versions of these tools that target a non-standard target
# `x86_64-linux-alpine-musl` which is a tweaked version of `x86_64-linux-unknown-musl` which 
# can perform dynamic linking but always with the musl runtime.
#
# This has some interesting properties which we'll explore in this sandbox, in particular 
# this custom x864_64-alpine-linux-musl target, unlike the official Rust target x86_64-unknown-linux-musl,
# dynamically links to musl.  So when we try to build statically with `target-feature=+crt-static`, the resulting
# binary is both dynamically and statically linked to MUSL, and a glorious segfault ensues.
#
# This is explained further in https://users.rust-lang.org/t/sigsegv-with-program-linked-against-openssl-in-an-alpine-container/52172
#
# I'm not alone in being stumped by this:
# https://www.reddit.com/r/rust/comments/j52wwd/overcoming_linking_hurdles_on_alpine_linux/
FROM alpine:3.14

RUN apk add --no-cache \
    curl \
    bash \
    make \
    perl \
    gcc g++ \
    gdb \
    git \
    nodejs npm \
    linux-headers \
    libudev-zero libudev-zero-dev \
    protoc \
    openssl openssl-dev openssl-libs-static \
    e2fsprogs e2fsprogs-dev e2fsprogs-extra e2fsprogs-libs e2fsprogs-static \
    xfsprogs xfsprogs-dev xfsprogs-extra xfsprogs-libs \
    musl-dev \
    openssl-dev \
    clang clang-dev clang-static \
    llvm-static llvm-dev \
    ncurses-static \
    zlib-static \
    rust cargo