TECH Signal 399
Developer makes Go stdlib packages work without libc in freestanding C
↗
The author extended Solod, a Go-to-C subset, so that 31 of its 37 standard-library packages compile and run in a freestanding C environment without libc.
This lets engineers reuse Go's standard library in low-level contexts such as microcontrollers, WebAssembly sandboxes, or kernels where no operating system or libc is available. However, because some built-in operations like memcpy still fall back to the libc symbol for large runtime sizes, truly freestanding builds remain limited to small-scale data moves.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Solod now provides 37 standard-library packages, with 31 of them functional in freestanding mode.
Freestanding builds rely on compiler builtins for memory and atomic operations, but large copies still reference libc memcpy.
The implementation uses conditional headers and a host/freestanding switch, applying known techniques without introducing novel mechanisms.
THE READ
What the cluster adds up to.
The core change is the porting of Go's standard library into a C subset that can be compiled with -ffreestanding and -nostdlib, eliminating dependence on libc. This involved creating a common header that conditionally includes hosted libc headers or provides only the freestanding-guaranteed ones. As a result, 31 out of 37 packages now build and run in environments lacking an operating system.
Adopting this approach requires developers to manage memory allocation, atomic operations, and error handling through custom macros and compiler builtins such as __builtin_trap and __builtin_alloca. The author documents the use of wrappers like so_alloca and so_panic to replace hosted equivalents. No new algorithms are introduced; the effort lies in adapting existing code to the freestanding constraints.
Where the method stops working is evident in operations that depend on runtime-size memory copies. The builtin __builtin_memcpy expands to inline code only for small, compile-time known sizes; for larger or variable sizes it emits a call to the memcpy symbol, which pulls in libc. Consequently, applications needing bulk data movement or facilities like file I/O, clocks, or entropy sources cannot run purely freestanding without providing those symbols themselves.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER