What the hell is a target triple?

Original Article ↗ Hacker News Discussion ↗

Use of “anachronism” and compiler history

  • Commenters dispute the intro’s use of “anachronism”: some say it’s technically correct for toolchains that only do native builds; others object that single‑target toolchains still exist and aren’t obviously historical relics.
  • Several emphasize cross‑compilers have existed since mainframes; “compilers only for the host” was never universally true.

GCC vs LLVM and cross‑compiling

  • Big contrast drawn between LLVM/Clang’s “one binary, many targets” and GCC’s per‑target binaries; some agree GCC’s model feels archaic and user‑hostile.
  • Others argue GCC’s modularity is deliberate and scales better when you need many exotic targets without installing dozens of unused backends.
  • There’s extensive criticism of the article’s strong anti‑GCC tone; people stress GCC’s historical importance and continued dominance in many distros.
  • Historical tidbit: LLVM was once offered to the FSF and the offer was effectively lost in Stallman’s email, which might have altered GCC’s trajectory.

Target triples: design, origin, and messiness

  • Several comments clarify that “triples” originated in GNU config (config.guess/config.sub), not LLVM; LLVM’s scheme is one variant among many.
  • Detailed breakdowns list up to 5–7 logical components: arch, vendor, kernel/OS, libc/userland, ABI, float ABI, object format. LLVM compresses some of these into its “environment” field.
  • Canonical vs non‑canonical triples, vendor field semantics, and Linux’s libc component all contribute to confusion.
  • Many agree the system is mostly accreted hacks: backwards‑compatibility, aliasing, and differing normalizations between projects (LLVM, GNU, Rust, etc.) make triples hard to reason about.
  • Some propose throwing triples away in favor of explicit structured parameters or per‑project fixed target lists (as Rust does).

ELF sections/segments and linker behavior (tangent)

  • Discussion of an earlier linker‑script post critiques its GCC bias and omission of segment (program header) details.
  • Debate over whether sections and segments are “the same concept”: consensus is they’re related metadata but serve different roles (development vs runtime).
  • Practical issues around embedding data into ELF, ensuring it’s mapped by LOAD segments, and using linker scripts vs custom tools are explored in depth.

Endianness

  • Observations that almost all modern mass‑market hardware is little‑endian; many developers happily static_assert(LE) and ignore BE.
  • Others warn this is risky for niche or legacy platforms (IBM Power/AIX, SPARC/Solaris, some ARM/MIPS modes, LEON in space, etc.), though such systems are rare.

Go, Zig, Rust and cross‑compilation ergonomics

  • Several Go developers defend Go’s GOOS/GOARCH scheme: it ships cross‑compilers out of the box, avoiding most of the “toolchain wiring” pain; mismatch with traditional triples is seen as a small price.
  • Zig is praised as the only toolchain that truly “just cross‑compiles,” including controlling glibc versions; commenters note that triples don’t encode glibc version, so they’re underspecified for serious Linux cross‑targeting.
  • Rust’s explicit target list and JSON target specs are cited as a saner, more structured layer over LLVM’s triples.

Linux, libc, and “no system libraries”

  • One thread argues Linux’s stable syscall ABI makes libc‑free static binaries viable; DNS and NSS issues are characterized as user‑space/glibc choices, not kernel constraints.
  • Others push back that, in practice, dropping glibc often breaks expectations (e.g., name resolution) and that alternative implementations sometimes violate standards.

Windows ARM64EC vs Rosetta

  • Multiple commenters strongly object to the article’s dismissal of Windows ARM64EC and praise it as a more flexible, incremental, and compatibility‑preserving design than Apple’s Rosetta approach.
  • They argue ARM64EC avoids fat‑binary bloat, allows fine‑grained porting, and better preserves UI and framework evolution.
  • There’s disagreement over how serious Rosetta 2’s real‑world drawbacks are; some maintain it’s effectively transparent for most users.

Naming bikesheds (x86_64 / amd64 / x64 / “quadruples”)

  • Debates over whether to prefer x86_64, amd64, or x64: the article’s prescriptive stance (“no one calls it x64”) is contradicted by several commenters.
  • Some defend amd64 as easier to type and widely used by distros; others prefer x86_64 as architecturally clearer.
  • The insistence on calling multi‑component identifiers “triples” is mocked; “tuple/moniker” is suggested as more accurate.

Perception of the article and blog

  • Many praise the technical depth, clarity on triples, and overall blog quality and design (especially the side preview), while noting performance quirks.
  • Others are put off by what they see as condescending language, factual slips (e.g., x32 status, protected mode history), and a harsh, dismissive stance toward GCC and some platform choices.