# static linking Published articles for static linking. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## C++ libraries linking DevFeed: [C++ libraries linking]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2026-07-29T19:07:38Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [C++](), [toolchain]() Tags: [build](), [build-tools](), [c-plus-plus](), [clang](), [compilation](), [directx](), [gcc](), [libraries](), [linux](), [macos](), [msvc](), [static-linking](), [toolchain](), [windows](), [x86]() ### AI overview The Red toolchain now supports statically linking C++ libraries, including their runtime, on Windows, Linux, and macOS. It accepts libraries built with MSVC, GCC, or clang through the existing import system and compilation switch, with platform-specific prerequisites and constraints. ### Source excerpt When we introduced static linking of C libraries, the promise was simple: name a .lib or .a archive in your #import, compile with -s, and ship one self-contained executable, no DLLs riding along, nothing to install on the target machine. There was one big frontier left, and everyone saw it coming: the libraries people want most (vision, GUI, audio, machine learning) are written in C++. A C++ library is a very different animal to link: it brings global constructors, exceptions, RTTI, templates, thread-local storage, and an entire language runtime that expects to be wired up just so. Until now, that was the line where you switched back to DLLs. That line is gone. The Red toolchain now statically links C++ libraries too (their runtime included) on every platform Red targets: Windows, Linux (x86 and ARM), and macOS. The best part: nothing changes. It is the same import system and same compilation switch: red -r -s myapp.red Libraries built with MSVC, GCC or clang are all accepted, in their native object formats. What you need preinstalled ➤ Windows: for C++ libraries (or C code built against Microsoft's static runtime), install the free Visual Studio Build Tools with the "Desktop development with C++" workload. Just one installer, and Red locates everything by itself: no vcvarsall, no PATH, no environment variables. Plain C libraries still need nothing at all and that now extends to C libraries touching COM, DirectX or MediaFoundation: the GUID constants such code references ship inside the toolchain, so a fresh Windows 11 with only red-toolchain executable on it links them! ➤ Linux: the GNU runtime archives from your distribution's gcc packages (libstdc++.a, libgcc.a and friends) placed next to your library. If one is missing, the linker names exactly what it needs. ➤ macOS: nothing beyond the toolchain; the system C++ runtime binds automatically. Some constraints 32-bit libraries for now, until the 64-bit toolchain is ready. The imported surface must be C (extern "C", ## Static linking support DevFeed: [Static linking support]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2026-06-29T18:39:33Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [toolchain](), [C](), [parquet](), [MSVC](), [Claude Code](), [codex]() Tags: [agents](), [c](), [claude-code](), [codex](), [compression](), [mod-player](), [msvc](), [soundtracker](), [static-linking](), [toolchain]() ### AI overview The Red toolchain now supports statically linking C libraries, allowing Red/System programs to be distributed as single self-contained executables. The article explains the linker's handling of object formats, symbols, sections, and relocations, and demonstrates the process with the miniz compression library. ### Source excerpt We must free ourselves of the hope that the sea will ever rest. We must learn to sail in high winds. -Aristotle Onassis The coding agents revolution is taking the world by storm and we are right in the middle of it. Like most of you, we have experimented with the agent's amazing (and frustrating) capabilities, pondering the role of Red and our vision in that new world. The conclusion is (un)surprisingly clear, Red is still very relevant and will be even more so as we improve it to better work with agents. In the meantime, here are some treats, starting with expanding our toolchain to support static linking of libraries written in C, allowing you to distribute single executables with all dependencies packed inside. This work has been done with the heavy assistance of frontier models and local harnesses (Claude Code and Codex). You might expect that to be a small addition, but a static linker has to read each platform's object format, pull in just the pieces it needs, fold duplicated sections, resolve system symbols and patch relocations by hand, so there was quite a bit of machinery to put together. The reward is the result everyone wants: a single, self-contained binary, with nothing to install beside it. A simple example Let's compress some data without shipping a compression library next to our program. For something concrete we will use miniz, a small, MIT-licensed library that implements the well-known zlib and deflate APIs. It is distributed as a single `miniz.c` / `miniz.h` pair, which makes it especially convenient to compile and link. The first step is to compile miniz into a static library. There are only two things to keep in mind. Red/System currently produces 32-bit code, so the object has to be 32-bit too; and it helps to switch off a couple of compiler extras (C++ exception tables and stack canaries) that would otherwise make the object reference runtime helpers we do not need. On Windows, with MSVC: cl /c /MT /GS- /EHs-c- /GR- miniz.c lib /out:miniz.l ## Call relocation types DevFeed: [Call relocation types]() Original publisher: [Read original article]() Published: 2026-02-16T08:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [x86](), [Assembly](), [Code]() Tags: [architectures](), [binutils](), [function](), [linker](), [static-linking](), [symbols](), [x86](), [x86-64]() ### AI overview This technical post explains why some architectures use separate ELF relocation types for direct function calls and tail calls. It contrasts static linking, where a PC-relative relocation can often be reused, with dynamic linking, where calls may use PLT indirection and therefore require relocation types that encode call semantics. ### Source excerpt Most architectures encode direct branch/call instructions with a PC-relative displacement. This post discusses a specific category of branch relocations: those used for direct function calls and tail calls. Some architectures use two ELF relocation types for a call instruction: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # i386, x86-64 call foo # R_386_PC32, R_X86_64_PC32 call foo@plt # R_386_PLT32, R_X86_64_PLT32 # m68k bsr.l foo # R_68K_PC32 bsr.l foo@plt # R_68K_PLT32 # s390/s390x brasl %r14, foo # R_390_PC32DBL brasl %r14, foo@plt # R_390_PLT32DBL # sparc call foo, 0 # not PIC: R_SPARC_WDISP30 call foo, 0 # gas -KPIC: R_SPARC_WPLT30 ## Blog: Introducing Falco 0.42.0 DevFeed: [Blog: Introducing Falco 0.42.0]() Original publisher: [Read original article]() Published: 2025-10-22T00:00:00Z Content type: release Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [Falco](), [container](), [Processes](), [static linking]() Tags: [bug](), [bug-fixes](), [dry-run](), [falco](), [features](), [memory-leak](), [performance](), [recording](), [release](), [static-linking]() ### AI overview Falco 0.42.0 introduces a capture recording feature that generates .scap files when detection rules trigger, including system-call traces for forensic analysis. The release also includes performance improvements, schema validation, configuration changes, and bug fixes. ### Source excerpt Dear Falco Community, today we are happy to announce the release of Falco 0.42.0! This release brings exciting new capabilities, including the capture feature, significant performance improvements, and important bug fixes that enhance Falco's capabilities. During this release cycle, we merged: 52 PRs on Falco, including 23 release note-worthy changes 110 PRs on Falco libs, including 47 release note-worthy changes 102 PRs on Falco drivers, including 29 release note-worthy changes We upgraded libs to version 0.22.1 and drivers to v9.0.0+driver. Thank you to our maintainers and contributors. This would not have been possible without your support and dedication! To learn everything about the changes, read on! What's new? TL;DR Key features: Capture recording feature; Drop enter initiative for performance; Plugin event schema validation; Thread table auto-purging configuration; Static fields; Key fixes: Fix thread table memory leak when parsing vfork (or equivalent clone/clone3 with CLONE_VFORK) exit from the caller process; Enable handling of multiple actions configured with syscall_event_drops.actions; Disable dry-run restarts when Falco runs with config-watching disabled; Fix abseil-cpp for Alpine build; Fix detection sandbox containers for CRI and containerd runtimes (container plugin); Stability improvements for container plugin and static linking of libgcc/libstdc++ for legacy compatibility; This release also comes with breaking changes that you should be aware of before upgrading. Major features and improvements The 0.42.0 release contains a new capture feature and significant performance improvements. Here is a list of the key new capabilities. Capture recording feature Falco 0.42.0 introduces the new capture recording feature, now available at sandbox maturity. This capability allows Falco to generate .scap files whenever a detection rule is triggered automatically. Each capture contains a detailed trace of system calls around the event, providing forensic-level ## Separation of Concerns in Cross-Compilation DevFeed: [Separation of Concerns in Cross-Compilation]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2024-01-30T00:00:00Z Content type: tutorial Language: en Sources: [Nixcademy Blog]() Topics: [Cross-Compilation](), [Nix](), [C++](), [Dependency management](), [Compiler](), [Dockerfile](), [static linking]() Tags: [c-plus-plus](), [compilation](), [compiler](), [cross-compilation](), [dependency-management](), [development](), [docker](), [static-linking]() ### AI overview This guide explains how Nix applies separation of concerns to cross-compilation in complex C++ projects. It discusses compiler selection, dependency management, external libraries, distribution, Docker-based workflows, and static linking. ### Source excerpt Master cross-compilation in complex C++ projects with Nix. Simplify dependency management, boost development speed, and reduce costs with this guide! ## Insomnihack22: Reversing a flawed ECC rng-as-a-service Go Server DevFeed: [Insomnihack22: Reversing a flawed ECC rng-as-a-service Go Server]() Original publisher: [Read original article]() Published: 2022-02-07T00:00:00Z Content type: tutorial Language: en Sources: [mahaloz.re]() Topics: [Go Language](), [Randomizer](), [servers](), [HTTP](), [debugging]() Tags: [crypto](), [ctf](), [ecc](), [game-hacking](), [go](), [ida](), [reversing](), [server](), [static-linking]() ### AI overview This write-up explains how to reverse a Go binary from the Insomnihack Teaser 2022 Nobus101 challenge. The binary provides an RNG service using a flawed P-256 elliptic-curve construction with reversible parameters, and the solution applies ideas from the Dual EC cryptography paper. ### Source excerpt Reversing a Go binary to find it generates flawed RNG from a P256 Elliptic Curve chosen with a reversible P and Q for number generation. Solution based on the Dual EC crypto paper.