Does official Blender run under Alpine/musl? #5

Closed
opened 2026-08-06 20:28:44 +00:00 by haylan · 2 comments
Owner

Question

Does the official Blender Linux tarball (as this image currently downloads from
download.blender.org/release/) run under Alpine/musl as-is, via gcompat, or not at all? Is
there a musl-friendly alternative that still supports headless .blend import for Godot (e.g. an
Alpine apk community Blender package, a different distribution channel, or a Flatpak-style
approach) — and if none exists, does that alone rule out Alpine for this effort?

Part of Smaller/faster godot-ci image (map).

## Question Does the official Blender Linux tarball (as this image currently downloads from `download.blender.org/release/`) run under Alpine/musl as-is, via `gcompat`, or not at all? Is there a musl-friendly alternative that still supports headless `.blend` import for Godot (e.g. an Alpine `apk` community Blender package, a different distribution channel, or a Flatpak-style approach) — and if none exists, does that alone rule out Alpine for this effort? Part of [Smaller/faster godot-ci image (map)](https://git.arthurerlich.de/haylan/godot-ci/issues/2).
haylan added the wayfinder:research label 2026-08-06 20:28:44 +00:00
Author
Owner

Researched: the official Blender Linux tarball (glibc >=2.28 required per blender.org) does NOT run on Alpine/musl as-is, and gcompat is not a credible fix for something Blender's size/complexity — gcompat's own docs say it only patches pre-built glibc binaries and 'some will still not work'; the one concrete community attempt (ikester/blender-docker PR#1) tried exactly this and failed with missing libs/unresolved glibc symbols. A musl-native alternative does exist — Alpine community's blender-headless package (5.2.0-r0) built for exactly this headless-import use case — but it's only on Alpine's edge branch, not a stable release, which is a real strike against Alpine for a pipeline that wants pinned versions. Full writeup + sources: https://git.arthurerlich.de/haylan/godot-ci/src/branch/research/blender-musl-alpine/docs/research/blender-musl-alpine.md

Researched: the official Blender Linux tarball (glibc >=2.28 required per blender.org) does NOT run on Alpine/musl as-is, and gcompat is not a credible fix for something Blender's size/complexity — gcompat's own docs say it only patches pre-built glibc binaries and 'some will still not work'; the one concrete community attempt (ikester/blender-docker PR#1) tried exactly this and failed with missing libs/unresolved glibc symbols. A musl-native alternative does exist — Alpine community's blender-headless package (5.2.0-r0) built for exactly this headless-import use case — but it's only on Alpine's edge branch, not a stable release, which is a real strike against Alpine for a pipeline that wants pinned versions. Full writeup + sources: https://git.arthurerlich.de/haylan/godot-ci/src/branch/research/blender-musl-alpine/docs/research/blender-musl-alpine.md
Author
Owner

Resolution already recorded on Smaller/faster godot-ci image (map)'s Decisions-so-far and acted on in ticket #7's resolution. Closing — this was left open by an oversight, not because it's still active.

Resolution already recorded on [Smaller/faster godot-ci image (map)](https://git.arthurerlich.de/haylan/godot-ci/issues/2)'s Decisions-so-far and acted on in [ticket #7](https://git.arthurerlich.de/haylan/godot-ci/issues/7)'s resolution. Closing — this was left open by an oversight, not because it's still active.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: haylan/godot-ci#5