Repository navigation
Implement static linking for --compile flag #16699
Description
What is the problem this feature would solve?
While compiling my test-program to an executable, I noticed that it depends on few external dynamic libraries. This is fine for most use cases, however, as I like to tinker around with embedded and stripped down systems, I might not always have the required libraries available on my system.
What is the feature you are proposing to solve the problem?
I would propose an extra flag to be added to be used in combination with --compile.
This could be something like --link static where the 2 allowed values would be 'static' and 'dynamic' where 'dynamic' would be the default.
I'm aware that static builds are larger, but I think that that is a reasonable sacrifice for the ability to just drop an executable into my system without worrying if I need to add libraries to my system.
What alternatives have you considered?
No response
Reacted by Marius Modlich, Adrien, Mira, Tamás Vince, 61soldiers, weishu, 3bl3gamer, PseudoResonance, Dmitriy Rodin, Oskar Sveinsen and 9 more
Activity
vexxvakan commentedon Jun 18, 2025
+1 from me, would love to have this feature because our entire build pipeline is based around supporting musl!
Bacto commentedon Jun 22, 2025
Hello,
Same here. I was totally surprised to discover that the binary generated is not statically built per default.
It would be really great if a static compilation feature could be added! 🙏
Bacto commentedon Jul 3, 2025
I've looked deeper and Bun uses its own binary as a base to generate the compiled binary file. Since Bun is not fully compiled statically, the generated binary is not either.
I'm actually surprised that Bun isn't statically compiled, as it statically compiles almost all the libraries it uses:
https://github.com/oven-sh/bun/blob/main/LICENSE.md#linked-libraries
In my case, I decided to recompile Bun in a static way:
bun run build:release -DCMAKE_EXE_LINKER_FLAGS="-static"The Bun binary gained around 600kB, going from 88MB to 88.6MB, which is negligible.
Given this, I think Bun could be statically compiled by default?
timmydo commentedon Sep 4, 2026
It'd be great to have this feature as I've had to create special config for Guix to run executables generated with Bun.
Claude Code cannot run on NixOS or Guix. It ships as a
bun build --compilebinary whose interpreter is hardcoded to
/lib64/ld-linux-x86-64.so.2, whichnon-FHS distros don't have. Users
patchelfit, and every auto-update delivers afresh binary that needs patching again. The reports land on the vendor's tracker,
where they can't be fixed, because the link mode is decided here:
OpenAI's Codex CLI is the same
kind of product with the same npm-wrapping-a-native-binary distribution. It's Rust,
built for
x86_64-unknown-linux-musl, andfilereports itstatic-pie linked. Itruns unmodified on the same Guix machine where the Bun build won't start. Rust and Go
give a portable single-file executable by default;
--compilecurrently can't.It would also remove a class of host-libc bugs. The glibc build is reported
crashing on hosts with glibc 2.44 (anthropics/claude-code#89909, #89732), where the
musl build works on the same machine. A static musl target makes the host libc
irrelevant and covers the
FROM scratchcase from #23910.