mold 1.0.1

mold 1.0 is a maintenance release of the high-speed linker. It contains a few new features and various bug fixes.

New features

• make install now creates /usr/local/libexec/mold/ld as a symlink to the mold executable. We do this for GCC. By passing -B/usr/local/libexec/mold, you can tell GCC to use ld inside that directory instead of /usr/bin/ld. (e8dcecf)
• xxHash library is now included in the mold's source tree as a subtree for ease of building. If you want to link against a libxxhash in a system library directory, pass SYSTEM_XXHASH=1 to make. (665bffa)
• The extern "C++" directive is now supported in the dynamic list. (7aa5c39)
• --color-diagnostics is supported. mold used to ignore that flag. (6e290aa)
• Not only * but also ? are now treated as special characters in the version script wildcard pattern. (31b0248)
• The --threads=N option has been added as an alias for --thread-count=N. (f9ff048)
• The following option has been added: --defsym (f6e8006), -z nodefaultlib (8c86c28), -z separate-code, -z noseparate-code and -z separate-lodable-segments (5601cf4), -z max-page-size (f3766cd)

Bug fixes and compatibility improvements

• mold now issue a warning instead of an error for an unknown -z option. (8bc5736)
• mold previously created a PT_NOTE segment for non-SHF_ALLOC note segments. This is a wrong behavior because we should create segments only for memory-allocated sections. This problem has been fixed. (76407a6)
• Previously, a version script can affect symbol visibility of undefined symbols when they are promoted to dynamic symbols. This is a semantically incorrect behavior and caused a libQt build failure (#151). The issue has been fixed. (3663389)
• Previously, mold silently turned unresolved undefined symbols into absolute symbols with value 0 if -shared, -z defs and -warn-undefined-symbols are specified. Even though this behavior makes sense, it's not compatible with GNU ld which promotes such symbols into dynamic symbols. This incompatibility causes a link failure for Firefox. Since 1.0.1, mold behaves the same as GNU ld. (04ccd4d)
• Previously, mold applied wrong values for relocations against Initial-Exec thread-local variables. That caused a link failure for Mesa 3D graphics library (#197). The issue has been resolved. (d116113)
• GCC 7 has a bug that it emits incorrect relocations against thread-local variables under a certain condition. That bug was unnoticed because existing linkers silently produces an output that works fine in most cases but is technically corrupted. mold used to check for that error condition and report an error. Now, mold does not report it as an error for the sake of bug-compatibility with GCC 7. I don't think relaxing the error check will cause any new issue to existing GCC 7 users, because if it does, they would have been experiencing the issue with existing linkers already. (d9606d6)
• If an output file has more than one sections for thread-local BSS, they were laid out in such that they are overlapping with each other. This bug caused a runtime error for programs compiled with DMD, a compiler for the D language (#126). This layout issue has been resolved. (b151de6)
• Previously, mold failed to look up correct files under --sysroot in some conditions. That caused a link failure for ClickHouse (#150). This bug has been fixed. (135f17c)

mold 1.0

mold 1.0 is the first stable and production-ready release of the high-speed linker. On Linux-based systems, it should "just work" as a faster drop-in replacement for the default GNU linker for most user-land programs. If you are building a large executable which takes a long time to link, mold is worth a try to see if it can shorten your build time. mold is easy to build and easy to use. For more details, see README.

mold is created by a person who knows very well as to how the Unix linker should behave, as I'm also the original creator of the current version of the LLVM lld linker.

There's no fancy new features in 1.0. Actually, 1.0 is very similar to 0.9.6. That being said, we'd like to make it clear by incrementing a major version number that mold for Linux is now stable.

Future plans

We are currently working on mold for macOS, and once it's complete, we'll release it as mold 2.0. After that, we'll work on mold for Windows and release it as 3.0.

mold 1.0's source tree has code for mold for macOS, but that's pre-alpha. Do not use it unless you know what you are doing.

Changes since mold 0.9.6

• -start-lib and -end-lib options are added for compatibility with GNU gold and LLVM lld.
• More ARM64 relocations are supported.
• Compatibility with glibc 2.2 or prior has improved. (#120)
• Compatibility with valgrind has improved. (#118)
• -Bno-symbolic option has been supported.
• -require-defined option has been supported.

mold 0.9.6

mold 0.9.6 is a maintenance release of the mold linker. This release contains only a single change to fix the following issue:

• mold used to create dynamic relocations for imported symbols when creating a position-dependent executable. That worked fine in an environment in which position-independent code (PIC) is enabled by default such as recent versions of most Linux distros. However, it failed with the "recompile with -fPIC" error if PIC was disabled and a dynamic relocation was created in a read-only section. mold 0.9.6 fixed the issue by creating copy relocations and PLTs for such symbols. (#116)

mold 0.9.5

mold 0.9.5 is a maintenance release of the mold linker.

Highlights of mold 0.9.5

• In 0.9.4, we changed the mold's behavior on remaining weak undefined symbols, so that they would be resolved to address zero if we were creating a shared object file with the -z defs option. Now, such symbols will be promoted to dynamic symbols so that they'll get another chance to be resolved at run-time. This change fixes a regression of Firefox build failure (#114), which depends on this particular linker behavior to export symbols from libxul.so.
• mold can now be built on macOS. Note that mold is still able to produce only ELF (Unix) files — so you can use it for cross compilation on macOS for Linux, but you can't use mold for macOS native development.
• Relocation overflow are now reported as errors on AArch64 and i386. Previously, such relocations were silently producing incorrect output.

mold 0.9.4

mold is a new linker that is optimized for modern multi-core machines. mold is command-line compatible with the other major linkers, GNU ld, GNU gold and LLVM lld, yet it is several times faster than them. Its goal is to increase programmer productivity by speeding up program build time, especially for rapid edit-build-test-debug cycles.

Highlights of mold 0.9.4

• mold -run now intercepts invocations of ld, ld.lld and ld.gold wherever they are in the directory hierarchy. Previously, they were intercepted only if they were in /usr/bin. This change was made because it is not uncommon to install a compiler toolchain into a directory other than the system bin directory.
• AArch64 (Arm 64-bit) support has been significantly improved. mold can now link many real-world programs including itself for AArch64.
• Fix an issue that relocation addends were not handled correctly for i386.
• mold is now able to link LLVM compiler-rt's CRT files.
• Fix an issue that a dynamic relocation was created for a read-only section if the relocation refers an unresolved weak symbol.
• Undefined weak symbols are now always resolved to address 0 instead of being promoted to dynamic symbols.

mold 0.9.3

mold is a new linker that is optimized for modern multi-core machines. mold is command-line compatible with the other major linkers, GNU ld, GNU gold and LLVM lld, yet it is several times faster than them. Its goal is to increase programmer productivity by speeding up program build time, especially for rapid edit-build-test-debug cycles.

Highlights of mold 0.9.3

• The --sysroot option is improved so that it's behavior is compatible with GNU ld.
• Intel TBB concurrency library is now statically-linked to the mold executable.
• mold gained the initial AArch64 (ARM64) support. It is still in alpha and not usable for production though.
• mold can now be built with musl libc instead of with GNU libc.
• The VERSION linker script command is now supported.
• mold is now even faster for object files containing a lot of mergeable string contents. Clang-13 with debug info is an example of such input. mold used to take ~3.6 seconds to link it on a simulated 10-core machine. mold v0.9.3 can link it in ~2.3 seconds. That is ~35% speedup.
• Other various minor compatibility issues have been fixed.

mold 0.9.2

mold 0.9.2 is a maintenance release of the mold linker. It contains only bug fixe. There's no new feature since 0.9.1. Here is a list of notable changes:

• Some test scripts are fixed so that they pass on non-Ubuntu-20 systems
• The logic to find the location of mold-wrapper.so is generalized so that mold can be installed other than /usr/bin or /usr/local/bin
• R_386_TLS_IE relocation has been implemented to fix a compatibility issue with GCC
• Some assertion failures are fixed
• mold no longer replaces IFUNC with FUNC in a .dynsym
• Section header is now properly aligned in memory and on disk

mold 0.9.1

This is the same version as 0.9 except that the version number is bumped up to 0.9.1. In mold 0.9, mold --version printed out 0.1.1 instead of 0.9.

mold 0.9

mold is a new linker that is optimized for modern multi-core machines. mold is command-line compatible with the other major linkers, GNU ld, GNU gold and LLVM lld, yet it is several times faster than them. Its goal is to increase programmer productivity by speeding up program build time, especially for rapid edit-build-test-debug cycles. (Disclaimer: I'm the original creator of the current version of LLVM lld.)

Highlights of mold 0.9

In the mold 0.9 release cycle, we focused on improving compatibility with other linkers. To find out compatibility issues, we tried to build all Gentoo Linux packages in a Docker environment with mold being set to /usr/bin/ld (the default linker's path) and also run their unittests if available. Gentoo was an ideal distro to conduct this test because of its source-based package system. We then analyzed all build and test failures one by one and fixed almost all issues during this release cycle.

Quantitatively speaking, among 6769 Gentoo packages that we could built with GNU ld, mold succeeded to build 6746 packages. This is ~99.7% success rate. A small number of packages were unable to be built with mold or failed to complete their unittests for various reasons. You can see our analysis of the failures on this spreadsheet.

So, we believe that as long as you are building your user-land program on a relatively new Linux distro, chances are mold will "just work" for your program. We don't want to set a bar too high, but we believe that you probably wouldn't notice any difference except a short program link time. We bumped the mold's version from 0.1.1 to 0.9 to show that mold is getting ready for production.

If you experience any compatibility issue, please file a bug at https://github.com/rui314/mold/issues.

Changes in mold 0.9

• Following options have been added: --warn-unresolved-symbols --error-unresolved-symbols --relocatable -z muldefs -z nodump -z origin --unique``--unresolved-symbols -z text -z textoff z notext -z keep-text-section-prefix --allow-multiple-definition --compress-debug-info=zlib{,-gnu,-gabi,none} -R --retain-symbols-file --warp --image-base
• mold used to embed its command line arguments to .comment section for traceability. Even though it's useful for debugging, it causes some OCaml tests which compare linker's output files byte-by-byte to fail. To appease them, mold embeds command line arguments to .comment only when MOLD_DEBUG environment variable is set to a non-empty string.
• mold now writes relocation addends to sections even for RELA-type dynamic relocations. This is for bug-compatibility with Go. Go's linker wrongly assumes that addends are always written to sections, although the correct value are in fact in RELA-type relocation themselves.
• mold now handles common symbols as if they were undefined symbols until a symbol resolution phase is done. This change makes an observable difference if an object file contains a common symbol and an archive file contains a non-common definition of the symbol. Previously, mold didn't pull out an object file from an archive to resolve a common symbol. Since mold 0.9, it pulls out an object file in that case. This change was made to build programs compiled with GNU Fortran.
• mold now exports undefined weak symbol as an undefined weak dynamic symbol, so that the symbol gets another chance to be resolved at load-time.
• .gnu.warning.* sections are now not only ignored but also discarded.
• mold no longer put local symbols to the dynamic symbol table. This change reduces the size of the dynamic symbol table.
• mold used to handle .ctors and .dtors sections as a normal section. These sections contain pointers to functions that are executed on program start up and exit. Today, their roles are superseded by .init_array and .fini_array sections. mold 0.9 now supports a feature to translate .ctors and .dtors to .init_array and .fini_array at link-time.
• mold now skips a library found by -l option if it's not for the target architecture. For example, mold skips libraries for i386 when creating an x86-64 executable.
• mold now defines end, etext and edata symbols.
• The version string displayed for --version now contains not only GNU ld but also GNU gold. This change appease some configure scripts that expect GNU gold in the --version string. (I wrote an essay about this kind of issue a few years ago.)
• The help message displayed for --help now contains supported targets and supported emulations strings to appease some configure scripts.
• If -z keep-text-section-prefix is given, mold now keeps .text.hot, .text.unknown, .text.unlikely, .text.startup, and .text.exit sections as they are instead of merging them into .text section. This change should slightly improve code locality at runtime, as hot code and cold code are aggregated to different places.
• Other various compatibility issues were fixed.

Demonstration

Here is a side-by-side comparison of per-core CPU usage of lld (left) and mold (right). They are linking the same program, Chromium executable.

As you can see, mold uses all available cores throughout its run and finishes quickly. On the other hand, lld fails to use available cores most of the time and takes much longer to finish. This is the Amdahl's law in action — only a limited number of internal passes of lld are parallelized, while almost all internal passes of mold are parallelized. On this demo, the maximum parallelism is capped to 16 so that the bars fit in the screen.

mold 0.1.1

mold is a multi-threaded, high-performance linker that is developed as a drop-in replacement for GNU ld, GNU gold and LLVM lld. It is several times faster than these linkers and command-line compatible with them with a few exceptions. Note that even though mold can compiler large user-land programs, such as Chrome, Firefox or Rustc, it is still experimental. Do not use mold for production unless you know what you are doing.

To use mold, download source using git clone and follow the instructions on README.

Changes

• More command-line options were added for compatibility with GNU linkers
• A man page was added
• mold executable no longer has a dependency to shared object files in a build directory, which enables us to install mold under /usr/bin and clean a build directory
• A script to build a statically-linked mold executable in a Docker environment was added, so that it is easy to build mold on any machine as long as Docker works
• Git subrepositories are automatically checked out by make now
• Various bugs were fixed