MOLD(1)

mold(1) — yes, the MOLD(1) page — is from the General Commands Manual, and ngl bestie, she's lowkey iconic. 💅✨ The way this linker shows up, slays, and makes the whole build feel main character? Obsessed. 🫶

✨ NAME ✨

• mold — a modern linker, periodt. 👑

🛠️ SYNOPSIS 🛠️

mold [option...] file...

💖 DESCRIPTION 💖

mold is a faster drop-in replacement for the default GNU ld(1). No cap. 🔥

🧚 How to use 🧚

See https://github.com/rui314/mold#how-to-use. That's the how-to, bestie. 💖

🌸 Compatibility 🌸

mold is designed as a drop-in replacement for the GNU linkers for linking user-land programs. If your user-land program cannot be built due to missing command-line options, please file a bug at https://github.com/rui314/mold/issues. fr fr. 🐛

mold supports a very limited set of linker script features, which is just sufficient to read /usr/lib/x86_64-linux-gnu/libc.so on Linux systems (on Linux, that file is contrary to its name not a shared library but an ASCII linker script that loads a real libc.so file.) 🌀

Beyond that, we have no plan to support any additional linker script features. The linker script is an ad-hoc, over-designed, complex language which we believe needs to be replaced by a simpler mechanism. We have a plan to add a replacement for the linker script to mold instead. 💅

🗂️ Archive symbol resolution 🗂️

Traditionally, Unix linkers are sensitive to the order in which input files appear on the command line. They process input files from the first (leftmost) file to the last (rightmost) file one-by-one. While reading input files, they maintain sets of defined and undefined symbols. When visiting an archive file (.a files), they pull out object files to resolve as many undefined symbols as possible and move on to the next input file. Object files that weren't pulled out will never have a chance for a second look. 💀 Not me crying over missed object files.

Due to this behavior, you usually have to add archive files at the end of a command line, so that when a linker reaches archive files, it knows what symbols remain as undefined. 🧠

If you put archive files at the beginning of a command line, a linker doesn't have any undefined symbols, and thus no object files will be pulled out from archives. You can change the processing order by using the --start-group and --end-group options, though they make a linker slower. 🐌

mold, as well as the LLVM lld(1) linker, takes a different approach. They remember which symbols can be resolved from archive files instead of forgetting them after processing each archive. Therefore, mold and lld(1) can "go back" in a command line to pull out object files from archives if they are needed to resolve remaining undefined symbols. They are not sensitive to the input file order. ✨

--start-group and --end-group are still accepted by mold and lld(1) for compatibility with traditional linkers, but they are silently ignored. 🙈

🌈 Dynamic symbol resolution 🌈

Some Unix linker features are difficult to understand without comprehending the semantics of dynamic symbol resolution. Therefore, even though it's not specific to mold, we'll explain it here. 👑

We use "ELF module" or just "module" as a collective term to refer to an executable or a shared library file in the ELF format. 🦋

An ELF module may have lists of imported symbols and exported symbols, as well as a list of shared library names from which imported symbols should be imported. The point is that imported symbols are not bound to any specific shared library until runtime. ⏳

Here is how the Unix dynamic linker resolves dynamic symbols. Upon the start of an ELF program, the dynamic linker constructs a list of ELF modules which, as a whole, consist of a complete program. The executable file is always at the beginning of the list followed by its dependent shared libraries. An imported symbol is searched from the beginning of the list to the end. If two or more modules define the same symbol, the one that appears first in the list takes precedence over the others. 🎯

This Unix semantics are contrary to systems such as Windows that have a two-level namespace for dynamic symbols. On Windows, for example, dynamic symbols are represented as a tuple of (symbol-name, shared-library-name), so that each dynamic symbol is guaranteed to be resolved from some specific library. 🪟

Typically, an ELF module that exports a symbol also imports the same symbol. Such a symbol is usually resolved to itself, but that's not the case if a module that appears before it in the symbol search list provides another definition of the same symbol. 🔁

Let's take malloc as an example. Assume that you define your version of malloc in your main executable file. Then, all malloc calls from any module are resolved to your function instead of the one in libc, because the executable is always at the beginning of the dynamic symbol search list. Note that even malloc calls within libc are resolved to your definition since libc exports and imports malloc. Therefore, by defining malloc yourself, you can overwrite a library function, and the malloc in libc becomes dead code. 💀

These Unix semantics are tricky and sometimes considered harmful. For example, assume that you accidentally define atoi as a global function in your executable that behaves completely differently from the one in the C standard. Then, all atoi function calls from any modules (even function calls within libc) are redirected to your function instead of the one in libc, which will very likely cause a problem. That is a somewhat surprising consequence for an accidental name conflict. On the other hand, this semantic is sometimes useful because it allows users to override library functions without rebuilding modules containing them. 😭

Whether good or bad, you should keep these semantics in mind to understand Unix linkers' behaviors. 🧠

🎀 Build reproducibility 🎀

mold's output is deterministic. That is, if you pass the same object files and the same command-line options to the same version of mold, it is guaranteed that mold produces the bit-for-bit identical output. The linker's internal randomness, such as the timing of thread scheduling or iteration orders of hash tables, doesn't affect the output. 🔒

mold does not have any host-specific default settings. This is contrary to the GNU linkers, for which some configurable values, such as system-dependent library search paths, are hard-coded. mold depends only on its command-line arguments. 🧚

🎀 OPTION NOTATIONS 🎀

Long options are spelled with two dashes. Some also accept a single dash, but which ones do is somewhat arbitrary for historical reasons. mold follows the conventions of other linkers for compatibility. For example, --export-dynamic can be spelled -export-dynamic, while --execute-only requires two dashes. 💅

This can cause unexpected behavior when constructing command-line options in a script. For example, you might use "-e$foo" to set the entry point symbol to the value of $foo. However, if $foo is xport-dynamic, the argument becomes -export-dynamic and is interpreted as --export-dynamic. 😱

To avoid such ambiguities, we recommend always using two dashes for long options and separating a single-letter option from its argument with a space. For example, use -e $foo or --entry=$foo to specify the entry point symbol in a script. 🫶

💅 MOLD-SPECIFIC OPTIONS 💅

• --chroot=dir — Sets dir as the root directory. That's it, that's the whole vibe. 🌸
• --color-diagnostics=[ auto | always | never ] — Shows diagnostic messages in color using ANSI escape sequences. auto means mold only prints the pretty colors when standard output is connected to a TTY. The default is auto. ✨
• --color-diagnostics — Synonym for --color-diagnostics=auto. Same thing, shorter to type, we love a shortcut. 🎀
• --no-color-diagnostics — Synonym for --color-diagnostics=never. For when you want your terminal to be boring on purpose.
• --detach, --no-detach — Permit — or don't permit — mold to create a debug info file in the background. That's the whole toggle. 🦋
• --fork, --no-fork — Spawns a child process and lets it do the actual linking. When you're linking a big program, the OS kernel can take a few hundred milliseconds to terminate a mold process, and --fork hides that latency. By default, it does fork.

Heads up though, bestie: --fork also hides the resource usage statistics reported by time(2), because it doesn't call waitpid(2) on the child process. If you actually need those stats, pass --no-fork. 💀

• --perf — Prints performance statistics. Numbers! For looking at! 🔥
• --print-dependencies — Prints out dependency information for input files.

Each line of the output for this option shows which file depends on which file in order to use a specific symbol. This one is genuinely a lifesaver for debugging why some object file in a static archive got linked, or why some shared library is still chillin' in an output file's dependency list even when you passed --as-needed. Detective mode activated. 🔍

• --relocatable-merge-sections — So by default, mold doesn't merge input sections by name when it's merging input object files into a single output object file for -r. Like, .text.foo and .text.bar aren't merged for -r, even though they do get merged into .text based on the default section merging rules.

This option flips the behavior so that mold merges input sections by name using the default section merging rules. 💅

• --repro — Archives your input files, plus a text file containing the command line options, all into a tar file, so you can run mold again with the exact same inputs. Iconic for reporting a bug with a reproducer, honestly. The output filename is path/to/output.tar, where path/to/output is the output filename you specified with -o. 🎁
• --reverse-sections — Reverses the order of input sections before assigning them their offsets in the output file.

This one is useful for finding bugs that depend on the initialization order of global objects. In C++, constructors of global objects in a single source file are guaranteed to be executed in source order, but there is no such guarantee across compilation units. Usually constructors get executed in the order given to the linker — but depending on that is a mistake, fr fr.

By reversing the order of input sections using --reverse-sections, you can easily test that your program still works in the reversed initialization order. 🧪

• --run command arg... — Runs command with mold as /usr/bin/ld. Specifically, mold runs the given command with the LD_PRELOAD environment set to intercept exec(3) family functions, and replaces argv[0] with itself if it is ld, ld.gold, or ld.lld. Sneaky? No. Iconic. 👑
• --separate-debug-file, --separate-debug-file=file — Bundles debug info sections into a separate file instead of embedding them in an output executable or a shared library. mold creates that debug info file in the background by default, so you can start running your executable ASAP. 🏃‍♀️

By default the debug info file is created in the same directory as the output file, with the .dbg file extension. That filename gets embedded into the output file so that gdb can automatically find the debug info file for the output file. For more info about gdb features related to separate debug files, see https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separate-Debug-Files.html.

mold holds a file lock with flock(2) while creating a debug info file in the background. 🔒

If you don't want a debug info file created in the background, pass the --no-detach option.

• --shuffle-sections, --shuffle-sections=number — Randomizes the output by shuffling the order of input sections before assigning them their offsets in the output file. If a number is given, it's used as the seed for the random number generator, so that the linker produces the same output for the same seed. If no seed is given, a random number is used as the seed. 🎲

This option is useful for benchmarking. Modern CPUs are super sensitive to a program's memory layout. A seemingly benign change in program layout — like a tiny size increase of a function in the middle of a program — can affect the program's performance. So even if you write new code and get a good benchmark result, it's genuinely hard to say whether the new code improves performance, because maybe the new memory layout just happens to perform better. 🙈

By running a benchmark multiple times with randomized memory layouts using --shuffle-sections, you can isolate your program's real performance number from the randomness caused by memory layout changes. Science, bestie. 🔬

• --spare-program-headers=number — Appends the given number of PT_NULL entries to the end of the program header, so that post-link processing tools can easily add new segments by overwriting those null entries.

Note that ELF requires all PT_LOAD segments to be sorted by p_vaddr. So if you add a new LOAD segment, you may need to sort the entire program header. Don't forget! 💀

• --stats — Prints input statistics.
• --thread-count=count — Uses count number of threads. Exactly that many. ⚡
• --threads, --no-threads — Uses multiple threads. By default, mold uses as many threads as the number of cores, or 32 — whichever is smaller. The reason it's capped at 32 is because mold doesn't scale well beyond that point. To use only one thread, pass --no-threads or --thread-count=1. 🌈
• --quick-exit, --no-quick-exit — Use — or do not use — quick_exit to exit. Simple as that.
• --zero-to-bss — Converts all-zero data sections into BSS.

When this option is enabled, mold scans input data sections that are not of type SHT_NOBITS and checks whether their contents consist solely of zero bytes. Those sections then get converted into BSS (SHT_NOBITS) sections. This reduces the size of the output file, since BSS sections occupy no space in the file image. ✨

This behavior is especially useful for user-defined sections created with __attribute__((section(".sectname"))) that contain uninitialized global variables. GCC and Clang don't automatically mark such sections as BSS even if their contents are entirely zero — instead they emit them as regular data sections. Rude, but okay. 😭

For example, consider __attribute__((section(".sectname"))) int vec[256];.

By default, this results in a .sectname section of type SHT_PROGBITS filled with zeros. With --zero-to-bss, the linker will recognize it as empty data and convert it to a SHT_NOBITS section, reducing the output file size without changing runtime semantics. Free real estate. 🍓

• -z rewrite-endbr, -z norewrite-endbr — Okay so gather round, this one's a whole story. 📖

As a security measure, some CPU instruction sets have recently gained a feature to protect control flow integrity by disallowing indirect branches by default. If that feature is enabled, the instruction executed immediately after an indirect branch must be a branch target marker instruction, or the CPU raises a fault. That marker instruction is also known as a "landing pad" instruction, and it's where indirect branches are allowed to land. This feature makes ROP attacks harder to conduct. 🛡️

To use the feature, a function whose pointer is taken needs to begin with a landing pad, because a function call via a function pointer is compiled to an indirect branch. On the other hand, if a function is called only directly (i.e. referred to only by direct branch instructions), it doesn't have to begin with one.

By default, the compiler always emits a landing pad at the beginning of each global function, because it doesn't know whether or not the function's pointer is taken in another translation unit. As a result, the resulting binary has more attack surface than necessary. 😬

If --rewrite-endbr is given, mold conducts a whole program analysis to identify functions whose addresses are actually taken, and rewrites landing pads with no-ops for non-address-taken functions, reducing the attack surface. ✨

This feature is currently available only on x86-64 and arm64.

On arm64, the landing pad is bti c. Note that code compiled with -mbranch-protection=standard (BTI + pointer authentication) starts functions with paciasp, which doubles as a landing pad — so there's no separate bti c to rewrite, and this option has no effect on such code. 🙅‍♀️

---

👑 GNU-COMPATIBLE OPTIONS 👑

• --help — Reports usage information to stdout and exits. The classic.
• -v, --version — Reports version information to stdout.
• -V — Reports version and target information to stdout. Extra info, extra slay. ⭐
• -E, --export-dynamic, --no-export-dynamic — When creating an executable, using the -E option causes all global symbols to be put into the dynamic symbol table, so that those symbols are visible from other ELF modules at runtime.

By default — or if --no-export-dynamic is given — only symbols that are referenced by DSOs at link-time are exported from an executable.

• -F libname, --filter=libname — Sets the DT_FILTER dynamic section field to libname. 🎀
• -I file, --dynamic-linker=file, --no-dynamic-linker — Sets the dynamic linker path to file. If no -I option is given, or if --no-dynamic-linker is given, no dynamic linker path is set to an output file. This is contrary to the GNU linkers, which do set a default dynamic linker path in that case. This difference doesn't usually make any difference though, because the compiler driver always passes -I to the linker. So it's giving... theoretical. 🦋
• -L dir, --library-path=dir — Adds dir to the list of library search paths from which mold searches libraries for the -l option. 💖

---

✨ okay also, real quick before we keep going: unlike the GNU linkers, mold does not have default search paths. And honestly? That rarely changes anything, because the compiler driver always passes all the necessary search paths to the linker anyway. 🫶

---

• -M, --print-map — writes a map file to stdout. dump it right into your terminal, queen 💅
• -N, --omagic, --no-omagic — forces mold to emit an output file with an old-fashioned memory layout. Two things happen: first, the first data segment is not aligned to a page boundary, and second, text segments get marked as writable if the option is given. vintage vibes, no cap ✨
• -S, --strip-debug — omits .debug_* sections from the output file. bye bye debug info 🦋
• -T file, --script=file — read a linker script from file.
• -X, --discard-locals — discards temporary local symbols to shrink the symbol table and the string table. What counts as "temporary"? Local symbols starting with .L — compilers generate those for unnamed program elements like string literals or floating-point literals. This is the default; use --discard-none if you want to keep them.
• --discard-none — keeps all local symbols in the symbol table, including the temporary ones starting with .L, except ones in mergeable sections. This restores the default behavior of GNU ld. Just so you know: mold and ld.lld discard temporary local symbols by default. 🙈
• -e symbol, --entry=symbol — and that's it, that's the whole entry in the page. No description, she just showed up with a colon and left 💀 (the original really is just this.)
• -f shlib, --auxiliary=shlib — sets the DT_AUXILIARY dynamic section field to shlib.
• -h libname, --soname=libname — sets the DT_SONAME dynamic section field to libname. This one's for when you're creating a shared object file. Like, typically when you create libfoo.so, you want to pass --soname=foo to the linker. iconic 🎀
• -l libname — searches for liblibname.so or liblibname.a from the library search paths.
• -m target — choose a target.
• -o file, --output=file — use file as the output file name instead of the default name a.out. (yes, a.out, the main character of 1971 👑)
• -r, --relocatable — instead of generating an executable or a shared object file, combine the input object files into another object file that can be used as an input to a linker. object files all the way down 🌀
• -s, --strip-all — omits the .symtab section from the output file.
• -u symbol, --undefined=symbol — if symbol is still undefined after reading all object files, and if there's a static archive containing an object file that defines symbol, pull that object file out and link it so the output file contains a definition of symbol. rescue mission activated 🫡
• -y symbol, --trace-symbol=symbol — trace references to symbol. internet sleuth mode 🔍
• --Bdynamic — link against shared libraries.
• --Bstatic — do not link against shared libraries.
• --Bsymbolic — when creating a shared library, makes global symbols export-only (i.e. it does not import the same symbol). The consequence is genuinely important: references within a shared library are always resolved locally, which negates symbol override at runtime. See "Dynamic symbol resolution" for more on symbol imports and exports. ✨
• --Bsymbolic-functions — same effect as --Bsymbolic but only for function symbols. Data symbols stay both imported and exported.
• --Bsymbolic-non-weak — same effect as --Bsymbolic but only for non-weak symbols. Weak symbols stay both imported and exported.
• --Bsymbolic-non-weak-functions — same effect as --Bsymbolic but only for non-weak function symbols. Data symbols and weak function symbols stay both imported and exported.
• --Bno-symbolic — cancels --Bsymbolic, --Bsymbolic-functions, --Bsymbolic-non-weak and --Bsymbolic-non-weak-functions. the uninvite button 🚫
• --Map=file — write the map file to file.
• --Tbss=address — alias for --section-start=.bss=address.
• --Tdata=address — alias for --section-start=.data=address.
• --Ttext=address — alias for --section-start=.text=address.
• --Ttext-segment=address — sets the address of the first byte of the text segment.
• --allow-multiple-definition — normally the linker errors out if a symbol has more than one definition. This option flips the default so it doesn't report an error for duplicate definitions, and instead uses the first definition. first come, first served 💅
• --allow-shlib-undefined, --no-allow-shlib-undefined — okay this one's important, listen up:

Even if mold successfully links a main executable with no undefined symbol errors, you can still run into symbol lookup errors at runtime, because the dynamic linker can't find some symbols in shared libraries in any ELF module. Why does that happen? Because mold ignores undefined symbols in shared libraries by default.

If you pass --no-allow-shlib-undefined, mold verifies that the undefined symbols in the shared libraries you gave the linker can actually be resolved at link-time. In other words — it converts that runtime error into a link-time error. glow up of the century ⭐

Heads up bestie: you need to pass all the shared libraries, including the indirectly dependent ones, to the linker as arguments for -l. If a shared library depends on a library that isn't passed to the linker, the verification gets skipped for that file. 😭

• --as-needed, --no-as-needed — by default, shared libraries given to the linker are unconditionally added to the list of required libraries in the output file. But libraries after --as-needed are added to that list only when at least one symbol is actually used by the output file. Translation: shared libraries after --as-needed don't get added to the list of needed libraries if the program doesn't need them. minimalism, we love her 🦋

The --no-as-needed option restores the default behavior for subsequent files.

• --build-id=[ md5 | sha1 | sha256 | fast | uuid | 0xhexstring | none ] — creates a .note.gnu.build-id section containing a byte string that uniquely identifies an output file. Here's the tea:
  • sha256 computes a 256-bit cryptographic hash of the output file and sets it to the build-id.
  • md5 and sha1 compute the same hash but truncate it to 128 and 160 bits respectively, before setting it to the build-id.
  • uuid sets a random 128-bit UUID.
  • 0xhexstring sets hexstring.
  • fast is a synonym for sha256.
• --build-id — synonym for --build-id=sha256.
• --no-build-id — synonym for --build-id=none.
• --compress-debug-sections=[ zlib | zlib-gabi | zlib:N | zstd | zstd:N | none ] — compresses DWARF debug info (.debug_* sections) using the zlib or zstd compression algorithm. Details, because numbers matter:
  • zlib-gabi is an alias for zlib.
  • zlib:N picks the zlib compression level, where N is between 0 and 9 (0 means no compression).
  • zstd:N picks the zstd compression level, where N is between 1 and 22.
  • Higher levels get you better compression ratios but are slower. 🐌
  • zlib is equivalent to zlib:1 and zstd is equivalent to zstd:3.
• --defsym=symbol=value — defines symbol as an alias for value.

value is either an integer (in decimal, or hexadecimal with a 0x prefix) or a symbol name. If you give an integer as the value, symbol is defined as an absolute symbol with that given value. 🔥

• --default-symver — uses the soname as a symbol version and appends that version to all symbols.
• --demangle, --no-demangle — demangles C++ and Rust symbols in log messages. readable logs, we stan 📖
• --dependency-file=file — writes a dependency file to file. The contents of the written file are readable by make(1), which defines exactly one rule with the linker's output file as a target and all input files as its prerequisites. The expectation is that you include the generated dependency file into a Makefile to automate dependency management. This option is analogous to the compiler's -MM -MF options. 🎀
• --dynamic-list=file — reads a list of dynamic symbols from file. Same as --export-dynamic-symbol-list, except that it implies --Bsymbolic. If file doesn't exist in the current directory, it gets searched from the library search paths, for the sake of compatibility with GNU ld.
• --eh-frame-hdr, --no-eh-frame-hdr — creates the .eh_frame_hdr section.
• --emit-relocs — the linker usually "consumes" relocation sections. Like, it applies the relocations to other sections, and the relocation sections themselves are discarded. --emit-relocs tells the linker to leave relocation sections in the output file. Some post-link binary analysis or optimization tools such as LLVM Bolt need them. 🔍
• --enable-new-dtags, --disable-new-dtags — by default mold emits DT_RUNPATH for --rpath. If you pass --disable-new-dtags, mold emits DT_RPATH for --rpath instead. choose your tag, bestie 💅
• --execute-only — again, that's the whole entry. no description, just the flag, standing there looking pretty ✨
• *--exclude-libs=libraries* ... — marks all symbols in the given libraries hidden. 🤫
• --export-dynamic-symbol=symbol — puts symbols matching symbol in the dynamic symbol table. symbol may be a glob pattern in the same syntax as for the --export-dynamic-symbol-list or --version-script options.
• --export-dynamic-symbol-list=file — reads a list of dynamic symbols from file.
• --fatal-warnings, --no-fatal-warnings — treats warnings as errors. no warnings, only consequences 😭
• --fini=symbol — calls symbol at unload-time.
• --gc-sections, --no-gc-sections — removes unreferenced sections. garbage collection era 🗑️✨
• --gdb-index — creates a .gdb_index section to speed up the GNU debugger. To actually use this, you need to compile your source files with the -ggnu-pubnames compiler flag.
• --hash-style=[ sysv | gnu | both | none ] — set the hash style.
• --icf=[ safe | all | none ], --no-icf — okay so it is genuinely not uncommon for a program to contain a ton of identical functions that differ only in name. Classic example: a C++ template std::vector is very likely to be instantiated to the exact same code for std::vector<int> and std::vector<unsigned>, because the container only cares about the size of the parameter type. Identical Code Folding (ICF) is a size optimization that identifies and merges these identical functions. twin magic 🔮

So, continuing the --icf tea ☕ — okay so if you pass --icf=all, mold goes full send and tries to merge, like, every single identical function it can find 🫶. It shrinks your output the most, bestie, but it is not a "safe" optimization — and this is the part where you gotta listen 👀. In C and C++ it's literally guaranteed that two pointers pointing at two different functions will never, ever be equal. But --icf=all breaks that assumption, because two identical functions end up with the same address after merging 😭. So you gotta be careful when you use this flag — make sure your program doesn't depend on function pointer uniqueness, fr fr. No cap.

--icf=safe is the cautious queen 👑 — it only merges functions when it's actually safe to do so. The logic is kinda iconic: if a program never takes the address of a function, then merging that function with another one is fine, because you literally cannot compare a function pointer with anything else without taking an address of a function first 💅.

--icf=safe needs a compiler that supports the .llvm_addrsig section, which carries the info about which symbols are address-taken. LLVM/Clang supports that section by default. GCC does not support it yet, so you can't use --icf=safe with GCC — it doesn't do any harm, but it can't optimize at all 🙈.

--icf=none and --no-icf disable ICF entirely. Periodt. ✨

---

• --ignore-data-address-equality — tells ICF to merge not just functions but data too 🍓. Only use this in combination with --icf=all, okay?
• --image-base=addr — sets the base address to addr. Simple as that 💜.
• --init=symbol — calls symbol at load-time 🌸.
• --no-undefined — reports undefined symbols, even when you're doing --shared 👀.
• --noinhibit-exec — creates an output file even if errors occur 😭. Chaotic but valid.
• --package-metadata=percent-encoded-string — embeds a specified string into the .note.package section 🎀. This one's designed for build scripts that generate binary packages — think .rpm or .deb — so they can include package metadata in each executable. It seriously simplifies the whole "which package does this executable or core file even belong to" detective work 🔍.

The argument gets treated as percent-encoded and decoded before being inserted into the section, which lets you dodge using the comma (,) character in the argument. Why does that matter? Because the compiler replaces all occurrences of commas in -Wl, with spaces before forwarding them to the linker — so commas are a whole mess 💀. Note that mold always interprets the argument as percent-encoded, so you also need to escape every occurrence of % as %25. Iykyk.

• --pack-dyn-relocs=[ relr | android | android+relr | none ] — compresses dynamic relocations in the output file 🦋.

If relr is specified, all R_*_RELATIVE relocations get put into the .relr.dyn section instead of .rel.dyn or .rela.dyn. Since .relr.dyn uses a space-efficient encoding scheme, this flag can literally shrink your output. It's typically most effective for position-independent executables ✨.

If android is specified, all dynamic relocations are encoded in Android's packed relocation format (APS2) and stored in the .rel.dyn or .rela.dyn section — whose section type changes to SHT_ANDROID_REL or SHT_ANDROID_RELA. The dynamic table gets updated to use DT_ANDROID_REL / DT_ANDROID_RELA and their SZ variants instead of the standard tags 👑

android+relr combines both: R_*_RELATIVE relocations go to .relr.dyn and the rest are APS2-encoded. This is the configuration used by most Android system binaries 🔥.

Heads up, bestie — a runtime loader has to support .relr.dyn to run executables or shared libraries linked with --pack-dyn-relocs=relr 😭. As of 2026, glibc (since 2.36), musl (since 1.2.4), Android, ChromeOS, and Fuchsia all support it. The APS2 format, on the other hand, is only handled by Android's bionic loader — the encoder itself is target-agnostic, but the produced binary can only be loaded on platforms where bionic (or a compatible loader) handles DT_ANDROID_REL(A). So don't just vibe-check it and assume 💀.

• --pie, --pic-executable, --no-pie, --no-pic-executable — creates a position-independent executable 🌈.
• --print-gc-sections, --no-print-gc-sections — prints the removed unreferenced sections 👀.
• --print-icf-sections, --no-print-icf-sections — prints folded identical sections 🎀.
• --push-state, --pop-state — --push-state saves the current values of --as-needed, --whole-archive, --static, and --start-lib. Those saved values can be restored by --pop-state 💅.

--push-state / --pop-state pairs can nest, bestie — they're stack girlies 📚.

These are so useful when you want to construct linker command line options programmatically. Example: if you wanna link libfoo.so on an as-needed basis but don't wanna change the global state of --as-needed, you can just append --push-state --as-needed -lfoo --pop-state to the linker command line options ✨.

• --relax, --no-relax — rewrites machine instructions with more efficient ones for some relocations. Enabled by default 🫶.
• --require-defined=symbol — like --undefined, except the new symbol must be defined by the end of the link 👀.
• --retain-symbols-file=file — keeps only the symbols listed in file. The file is a text file containing a symbol name on each line. mold discards all local symbols as well as global symbols that aren't in file. Note that this option removes symbols only from the .symtab section and does not affect the .dynsym section, which is the one used for dynamic linking 💜.
• --rpath=dir — adds dir to the runtime search paths 🌸.
• --section-start=section=address — sets address to section. The address is a hexadecimal number that may start with an optional 0x 🎀.
• --shared, --Bshareable — creates a share library ✨.
• --spare-dynamic-tags=number — appends the given number of DT_NULL entries to the end of the .dynamic section, so post-link processing tools can easily add new dynamic tags by overwriting the null entries 👑.
• --start-lib, --end-lib — handles object files between --start-lib and --end-lib as if they were in an archive file. That means object files between them are linked only when they're needed to resolve undefined symbols 🦋. These are useful when you wanna link object files only when needed but also wanna avoid the overhead of running ar(3) — efficiency queen 💅.
• --static — do not link against shared libraries. Simple.
• --sysroot=dir — sets the target system root directory to dir 🌈.
• --trace — prints the name of each input file 🔍.
• --undefined-glob=pattern — synonym for --undefined, except --undefined-glob takes a glob pattern instead of just a single symbol name ✨.
• --undefined-version, --no-undefined-version — by default, mold warns on a symbol specified by a version script or by --export-dynamic-symbol if it's not defined. You can silence the warning with --undefined-version 🫶.
• --unique=pattern — don't merge input sections that match the given glob pattern pattern 🙈.
• --unresolved-symbols=[ report-all | ignore-all | ignore-in-object-files | ignore-in-shared-libs ] — how to handle undefined symbols. That's the whole vibe check 👀.
• --version-script=file — reads a version script from file. If file doesn't exist in the current directory, it's searched from the library search paths for the sake of compatibility with GNU ld 💜.
• -w, --no-warnings — suppresses warnings and cancels --fatal-warnings 🤫.
• --warn-common, --no-warn-common — warns about common symbols 👀.
• --warn-once — only warns once for each undefined symbol, instead of warning for each relocation referring to an undefined symbol. Life saver 😭.
• --warn-unresolved-symbols, --error-unresolved-symbols — normally the linker reports an error for unresolved symbols. --warn-unresolved-symbols turns that into a warning, and --error-unresolved-symbols restores the default behavior 🎀.
• --whole-archive, --no-whole-archive — when archive files (.a files) are given to the linker, only object files needed to resolve undefined symbols are extracted from them and linked to an output file. --whole-archive changes that behavior for subsequent archives, so the linker extracts all object files and links them to the output 💅. For example, if you're creating a shared object file and you want all archive members included in the output, you should pass --whole-archive. And --no-whole-archive restores the default behavior for subsequent archives ✨.
• --wrap=symbol — makes symbol resolve to __wrap_symbol. The original symbol can be resolved as __real_symbol 🦋. Typically used for wrapping an existing function.
• -z cet-report=[ warning | error | none ] — Intel Control-flow Enforcement Technology (CET) is a new x86 feature available since Tiger Lake (released in 2020) 👑. It defines new instructions to harden security and protect programs from control hijacking attacks. You can tell the compiler to use the feature by specifying the -fcf-protection flag 🔥.

The -z cet-report flag makes sure all object files were compiled with a correct -fcf-protection flag. If warning or error is given, mold prints out a warning or an error message if an object file was not compiled with the compiler flag 😤.

mold looks for the GNU_PROPERTY_X86_FEATURE_1_IBT bit and the GNU_PROPERTY_X86_FEATURE_1_SHSTK bit in the .note.gnu.property section to determine whether an object file was compiled with -fcf-protection 🔍.

• -z now, -z lazy — by default, functions referring to other ELF modules are resolved by the dynamic linker when they're called for the first time. -z now marks an executable or shared library file so that all dynamic symbols are resolved when the file is loaded into memory ✨. -z lazy restores the default behavior 💅.
• -z origin — marks the object as requiring immediate $ORIGIN processing at runtime 🌸.
• -z ibt — turns on the GNU_PROPERTY_X86_FEATURE_1_IBT bit in the .note.gnu.property section to indicate that the output uses IBT-enabled PLT 🎀. This option implies -z ibtplt.
• -z ibtplt — generates an Intel Branch Tracking (IBT)-enabled PLT, which is the default on x86-64. Yeah, this is the default 👑.

okay continuing our -z era, bestie, we're so back 💅

• -z execstack, -z noexecstack — real talk, by default the pages for the stack area (aka the pages where your local variables live) are not executable, and that's for security reasons, periodt. -z execstack makes them executable. -z noexecstack puts the default behavior back. 🫶
• -z keep-text-section-prefix, -z nokeep-text-section-prefix — keeps .text.hot, .text.unknown, .text.unlikely, .text.startup, and .text.exit as separate sections in the final binary instead of merging them all into .text. like let them have their own identity bestie ✨
• -z rodynamic — makes the .dynamic section read-only. 🔒
• -z relro, -z norelro — okay so some sections like .dynamic only have to be writable while a module is being loaded into memory. Once the dynamic linker finishes its job, nobody's gonna mutate those sections ever again. As a security mitigation, it's preferred to make those segments read-only while the program runs.

-z relro puts those sections into a special segment called relro. The dynamic linker makes a relro segment read-only after it finishes its job.

By default, mold generates a relro segment. -z norelro disables the feature. 🙈

• -z sectionheader, -z nosectionheader — -z nosectionheader tells the linker to omit the section header. By default, the linker does not omit the section header. that's the whole vibe 💀
• -z separate-loadable-segments, -z separate-code, -z noseparate-code — if one memory page contains multiple segments, the page protection bits get set so that the needed attributes (writable or executable) are satisfied for all the segments. This usually happens at a boundary of two segments with two different attributes.

separate-loadable-segments adds paddings between segments with different attributes so they don't share the same page.

separate-code adds paddings only between executable and non-executable segments.

noseparate-code adds no paddings between segments at all. This is the default. 🎀

• -z defs, -z undefs — reports undefined symbols (even with --shared). no cap, it will tell you 👑
• -z shstk — enforces shadow stack by turning the GNU_PROPERTY_X86_FEATURE_1_SHSTK bit in the .note.gnu.property output section. Shadow stack is part of Intel Control-flow Enforcement Technology (CET), which is available since Tiger Lake (2020). iconic hardware era ⭐
• -z start-stop-visibility=[ hidden | protected ] — if a section name is valid as a C identifier (i.e. it matches /^[_a-zA-Z][_a-zA-Z0-9]*$/), mold creates __start_SECNAME and __stop_SECNAME symbols to mark the beginning and end of the section, where SECNAME is the section name.

You can make these marker symbols visible from other ELF modules by passing -z start-stop-visibility=protected. Default is hidden. 🦋

• -z text, -z notext, -z textoff — mold by default reports an error if dynamic relocations are created in read-only sections. If -z notext or -z textoff are given, mold creates such dynamic relocations without reporting an error. -z text restores the default behavior. choose your fighter 😭
• -z max-page-size=number — some CPU ISAs support multiple memory page sizes. This option specifies the maximum page size that an output binary can run on. In general, binaries built for a larger page size can run on a system with a smaller page size, but not vice versa. The default value is 4 KiB for i386, x86-64, and RISC-V, and 64 KiB for ARM64. math girlie behavior 🧚
• -z nodefaultlib — makes the dynamic loader ignore default search paths.
• -z nodelete — marks the DSO non-deletable at runtime.
• -z nodlopen — marks the DSO not available to dlopen(3). This option makes it possible for the linker to optimize thread-local variable accesses by rewriting instructions for some targets. ✨
• -z nodump — marks the DSO not available to dldump(3).
• -z nocopyreloc — do not create copy relocations.
• -z initfirst — marks the DSO to be initialized first at runtime. main character energy fr fr 👑
• -z interpose — marks the object to interpose all DSOs but the executable.
• -(, -), -EL, -Onumber, --dc, --dp, --end-group, --no-add-needed, --no-copy-dt-needed-entries, --nostdlib, --rpath-link=Ar dir, --sort-common, --sort-section, --start-group, --warn-constructors, --warn-once, --fix-cortex-a53-835769, --fix-cortex-a53-843419, -z combreloc, -z common-page-size, -z nocombreloc — Ignored. 💀 that's it, that's the whole entry, they're just there vibing.

---

🌸 ENVIRONMENT VARIABLES 🌸

• MOLD_JOBS — if this variable is set to 1, only one mold process will run at a time. If a new mold process is initiated while another is already active, the new process will wait until the active one completes before starting. 🫶

The primary reason for this environment variable is to minimize peak memory usage. Since mold is designed to operate with high parallelism, running multiple mold instances simultaneously may not be beneficial. If you execute N instances of mold concurrently, it could require N times the time and N times the memory. On the other hand, running them one after the other might still take N times longer, but the peak memory usage would be the same as running just a single instance.

If your build system invokes multiple linker processes simultaneously and some of them often get killed due to out-of-memory errors, you might consider setting this environment variable to 1 to see if it addresses the OOM issue. 🧚

Currently, any value other than 1 is silently ignored. (yes, silently, it's not gonna tell you 🙈)

• MOLD_DEBUG — if this variable is set to a non-empty string, mold embeds its command-line options in the output file's .comment section. little diary entry, love that for us 💖
• MOLD_REPRO — setting this variable to a non-empty string has the same effect as passing the --repro option. ✨

---

🦋 SEE ALSO 🦋

gold(1), ld(1), elf(5), ld.so(8)

the whole friend group honestly 💜

---

👑 AUTHOR 👑

Rui Ueyama ruiu@cs.stanford.edu

---

🌈 BUGS 🌈

Report bugs to https://github.com/rui314/mold/issues.

like actually report them, don't just suffer in silence bestie 😭

---

aaand that's the whole page, we ate, no crumbs 🍓 this icon of a manpage is from October 2026, section MOLD(1) — go forth and link things, ily, bye 💅✨