Red Programming Language: Static Linking Support

"We must free ourselves of the hope that the sea will ever rest." — Aristotle Onassis

The landscape of software development is currently being reshaped by the coding agents revolution. Like many of you, the Red team has been exploring the impressive—yet occasionally erratic—capabilities of these agents, questioning how Red fits into this evolving paradigm.

The conclusion is clear: Red remains highly relevant. In fact, as we refine the language to be more "agent-friendly," its value will only increase.

To that end, we are introducing a significant toolchain expansion: support for the static linking of C libraries. This allows developers to distribute single, standalone executables with all necessary dependencies embedded within the binary.

The Engineering Behind the Feature

This milestone was achieved with substantial help from frontier AI models and local environments, specifically Claude Code and Codex.

While it might seem like a minor tweak, implementing a static linker is a complex task. The toolchain must now:

1. Parse the specific object format of the target platform.
2. Extract only the required code segments.
3. Merge duplicated sections.
4. Manually resolve system symbols and patch relocations.

The end goal is the "holy grail" of distribution: $\text{Binary} + 0 \text{ Dependencies} = \text{Portable App}$.

The Linking Workflow

---

Practical Example: Integrating miniz

To demonstrate, let's implement data compression without requiring the user to install a separate library. We'll use miniz, a lightweight MIT-licensed library providing zlib and deflate APIs. Since it consists of just miniz.c and miniz.h, it is ideal for this purpose.

1. Compilation

Because Red/System currently generates 32-bit code, the object file must also be 32-bit. We must also disable certain compiler features (like stack canaries and C++ exception tables) to avoid unnecessary runtime dependencies.

On Windows using MSVC:

cl /c /MT /GS- /EHs-c- /GR- miniz.c lib /out:miniz.lib miniz.obj

2. Red/System Mapping

We map the required functions using an extension-less name ("miniz").

[Title: "miniz round-trip"]
#import [ "miniz" cdecl [ 
    compress: "mz_compress" [ 
        dst [byte-ptr!] dst-len [int-ptr!] src [byte-ptr!] src-len [integer!] 
        return: [integer!] 
    ] 
    uncompress: "mz_uncompress" [ 
        dst [byte-ptr!] dst-len [int-ptr!] src [byte-ptr!] src-len [integer!] 
        return: [integer!] 
    ] 
]]

3. Choosing the Linkage

The toolchain uses the extension-less name to decide how to link based on your command-line flags:

By using the -s (or --static) flag, the mz_compress and mz_uncompress functions are baked directly into the executable. The result is a binary under 50 KB that requires no PATH configuration or installer.

---

Granular Control and Compatibility

While extension-less names are convenient for global switching, you can still be explicit. If you provide a specific extension, the toolchain honors it regardless of the -s flag.

This is useful for hybrid linking:

• #import ["user32.dll" stdcall [...]] $\rightarrow$ Always Dynamic
• #import ["miniz.lib" cdecl [...]] $\rightarrow$ Always Static (Windows)
• #import ["libminiz.a" cdecl [...]] $\rightarrow$ Always Static (Linux/macOS)

Backward Compatibility: Any existing code that explicitly names .dll, .so, or .dylib files will continue to function exactly as before.

---

Supported Platforms

Static linking is available across all primary native targets:

• Windows (x86): COFF objects/libraries (.obj, .lib)
• Linux (x86): ELF objects/archives (.o, .a)
• Linux ARM (inc. Raspberry Pi): ELF ARM (ARM and Thumb-2)
• macOS (Intel): Mach-O objects/archives

Cross-compilation remains seamless. For instance, running red -t RPi -s will produce a standalone ARM binary on your desktop, ready for immediate deployment to a Pi.

---

Real-World Application: CherryTracker

To stress-test these capabilities, I developed CherryTracker, a soundtracker-style mod player.

This project was a collaboration with AI agents. While it took dozens of iterations to polish and required several manual passes to refine the code style, it serves as a great proof of concept.

Technical Stack:

• UI: Red (Draw-based)
• Processing: Red/System (for high-speed data handling)
• Backend: libxmp (statically linked 32-bit libraries for decoding mod formats)

Pre-built binaries for Linux and Windows (signed with a personal certificate) are available via the repository, along with a collection of mods from ModArchive.