December 29, 2025
When binaries go thicc
Binaries
25GB mega-apps spark panic, pedants, and punchlines
TLDR: An engineer says mega-companies ship 25GB one-file programs and hit a 2GB call-limit quirk, forcing new build tactics. Comments explode: one side demands shared libraries, another defends static simplicity, while nitpicks and jokes fly—highlighting a real tension between startup speed, debuggability, and keeping deployments sane.
Forget “apps”—some mega-companies are shipping single program files so huge they’d make your hard drive blush: up to 25GB, the author claims. Why? They bundle all code into one executable (aka static linking) to start fast and avoid deployment fuss. On x86-64 chips, there’s a “relocation barrier” around 2GB because the CALL instruction only reaches nearby code, forcing new build tricks when binaries go supersized. Think of an ELF file (a Linux program) stuffed with everything, plus heavy “debug symbols” used for troubleshooting. The post suggests compiler flags to cope; then the peanut gallery shows up—ready to fight, joke, and nitpick.
Commenters split into camps. Shocked folks: “25GB is horrifying, please use shared libraries” (dynamic linking is the opposite of bundling everything). Pragmatists cheer the “ship one file” dream: fewer moving parts, faster startup. C++ veterans blame template-heavy libraries like Eigen for “thicc binaries.” Pedants pounce, correcting the author’s wording about jumps versus calls—pure nerd theater. Meanwhile, meta-drama erupts: “Even the title got sanitized,” one user quips, as “Huge Binaries” becomes “Binaries.” Jokes fly: forklift memes, “my debugger weighs more than my cat,” and endless riffs on “thicc.exe.” It’s performance vs sanity, and nobody’s backing down on HN today, folks.
Key Points
- •Mega-codebases can produce extremely large statically linked ELF binaries, exceeding 25 GiB with debug symbols.
- •On x86_64, the CALL instruction uses a 32-bit signed relative offset, limiting reachable code to ±2 GiB from the call site.
- •This limitation creates a 2 GiB “Relocation Barrier” that complicates linking and code layout in very large binaries.
- •A minimal C example demonstrates how relocations (R_X86_64_PLT32) are recorded and resolved by the linker using tools like objdump and readelf.
- •The article argues that crossing the barrier necessitates rethinking how code is linked and built for massive static binaries.