- Update to version 2.31.0
  * mold is now up to 10% faster when linking very large, debug info-enabled
    executables such as Blender (~1.8 GiB) or Clang (~3.8 GiB), thanks to several
    improvements we've made to the string merging algorithm. (53ebcd8, d714301,
    40f6b17, c9faf3d)
  * -z start-stop-visibility=hidden is now supported so that linker-synthesized
    __start_<section-name> and __stop_<section-name> symbols can be completely
    hidden from other ELF modules. Previously, only -z
    start-stop-visibility=protected was supported. (99a5b15)
  * -Bsymbolic-non-weak and -Bsymbolic-non-weak-functions options are now supported
    for compatibility with LLVM lld. Just like lld, these options control which
    symbols are exported as dynamic symbols. -Bsymbolic-non-weak makes the linker to
    export only weak symbols, whereas -Bsymbolic-non-weak-functions makes it to
    export only weak function symbols. (7d17aa8)
  * Previously, if a linker script contains a newline character in the beginning
    four bytes of a file, it was not recognized as a linker script by mold. Now,
    mold allows newlines at the beginning of a file. (ea054cc)
  * Under rare circumstances, the INPUT linker script command may have found a
    different file than GNU ld would. Now, mold's behavior aligns with GNU ld's.
    (163975d)
  * Previously, the --repro option produced corrupted tar files. Now the bug has
    been fixed. (32c4a09)
  * mold generally guarantees that its output is reproducible, meaning that if you
    run the linker with the exact same command line options and input files, the
    output is guaranteed to be bit-for-bit identical to the previous outputs.
    However, under rare circumstances, it might produce different output due to a
    bug. It's reported that this nondeterminism caused random crashes for some
    programs (#1247). This bug has been fixed. (6463a7c)
  * mold no longer sets the address of the .text section as the entry point address
    if --entry option is not given, just like LLVM lld. (020b1a7)

• Files Changed
• Browse Source

- Update to version 2.30.0
  * We have increased the version number from 2.4.1 to 2.30.0, even though this
    release contains only minor bug fixes. This change was made to prevent GNU
    libtool from mistaking mold 2.4.1 for GNU ld 2.4.1, which led it to incorrectly
    conclude that our linker was an outdated version of the GNU linker. Bumping up
    the version number to align with GNU ld may not be the most elegant solution,
    but it is a practical approach to resolve the compatibility issue with GNU
    libtool. (c7f6a91)
  * Previously, mold may have inserted an unnecessary gap before the .bss section in
    an output file, thereby creating an extra segment for it. While not technically
    incorrect, it was certainly unnecessary. mold 2.30.0 eliminates this unnecessary
    on-disk gap for .bss. (c395da1)
  * Previously, under rare circumstances, mold might fail with the "ConcurrentMap is
    full" error message if --gdb-index was used. This bug has been resolved.
    (c60d1d0)
  * Previously, mold might generate an excessive number of "ignoring .llvm_addrsig
    section without sh_link" warnings. These warnings are now suppressed. (51f871f)
  * Sections with unknown section types are now reported as errors. (d21207c)
  * [PPC32] A crash bug related to --gc-sections has been fixed. (8eae0a3)

• Files Changed
• Browse Source

- Align path for document installation between openSUSE versions.

- Update to version 2.4.1
  * mold 2.4.0 or prior may promote weak dynamic symbols to strong ones under a rare
    circumstance, which caused "undefined symbol" error at runtime. The bug has been
    fixed. (50bdf39)
  * Previously, if two or more VERSION clauses in a version script match to the same
    symbol, the first one took precedence. This was incompatible with GNU ld, which
    gives the last one the highest priority, causing a Qt library link failure. This
    compatibility issue has been resolved. (e1e16bf)
  * By default, we demangle symbols in error messages so that they are easier to
    read. Previously, Rust symbols could accidentally be demangled as C++ symbols.
    Now, mold attempts to demangle symbols as Rust ones only for object files
    created by rustc. (ea9864b)
  * [RISC-V] mold now relaxes a GOT-load instruction sequence into a direct address
    materialization if the symbol address is known at link time. This relaxation
    eliminates one memory load and slightly improves the linked program's
    performance. (2ccaa81)
  * [PowerPC64 ELFv2] GCC may emit references to _savegpr0_*, _restgpr0_*,
    _savegpr1_* and _restgpr1_* symbols for the -Os command line option to optimize
    the output for code size. These symbols are not defined by any object file and
    expected to be synthesized by the linker. mold didn't use to synthesize these
    symbols, and therefore object files created with -Os sometimes failed due to
    missing symbol errors. Now, mold synthesizes these symbols. (d4ff48a)
  * [PowerPC64] R_PPC64_DTPREL16_LO_DS relocation type has now been supported.
    (6d8e6af)
  * [Illumos] On Illumos OS, absolute symbols in DSOs need to be resolved at runtime
    because the dynamic linker treats such symbols in a special manner. Previously,
    mold directly used absolute symbol addresses at link-time and did not place them
    into the dynamic symbol table. That optimization has been removed for

• Files Changed
• Browse Source

- Update to version 2.4.0
  * mold gained the --spare-program-headers=<number> option, which adds a specified
    number of spare entries at the end of the program header. The option aims to
    make post-processing tools to add program header entries very easily. Note that
    sorting program header entries after adding new ones may be necessary to meet
    the constraints of the ELF file format. For details, see the elf(5) man page.
    (eb6c213)
  * mold's -z rewrite-endbr option rewrites superflous endbr64 instructions with nop
    as a countermeasure against control-flow highjacking attacks. Previously, this
    worked exclusively with object files compiled with -ffunction-sections,
    requiring each function to be compiled into a separate section. Starting from
    this release, -z rewrite-endbr works on object files compiled without it. In
    other words, mold is now capable of rewriting endbr64 instructions even if the
    instruction is not at the beginning of a section. (3cb8a52)
  * Previously, mold couldn't handle object files containing multiple .eh_frame
    sections. The .eh_frame is a section containing data for exception handling.
    Usually, an object file contains only one .eh_frame which describes how to
    handle exceptions for all text sections in the same file. However, on rare
    conditions, it seems ld -r creates an object file containing multiple .eh_frame
    sections. mold is now able to handle such object files. (f4c5a8a)
  * mold -run <command> is an easy way to run the given command with a virtual
    environment in which the ld command is replaced with mold. The feature is
    implemented using LD_PRELOAD to hook fork(2)-family functions. Before this
    release, some invocations of ld were not intercepted correctly because we missed
    the posix_spawnp(2) function. Now, the function is intercepted just like other
    fork(2)-family functions. (3fd1cec)
  * mold used to produce a non-working executable on a rare occasion when all
    thread-local variables lacked an initial value and the read-only data required
    alignment equal to or greater than the page size. This bug has been resolved.
    (de7d37e)

• Files Changed
• Browse Source

- Update to version 2.3.3
  * --dynamic-list has different semantics for executables and DSOs. Previously,
    mold implemented only the semantics for executables, causing issues with
    libraries such as musl that used this option. mold now handles the option for
    DSOs correctly. (da3f5dd)
  * Old object files often contain .ctors and .dtors sections, which hold function
    pointers for initializing and finalizing processes, respectively. Their roles
    have been superseded by .init_array and .fini_array on most targets. mold worked
    functioned correctly as long as input object files consistently use the old or
    the new sections. However, mixing object files that contain both types of
    initializers/finalizers resulted in some functions not being executed. This
    issue has been fixed. (3f88964)
  * --defsym can cause the linker to crash if a given symbol is not defined. The
    crash bug has been fixed. (ff3d54d)
  * [POWER10] On rare occasions, pointers statically initialized to functions could
    be left as null pointers. This bug has been fixed. (31c3b53)
- Remove upstreamed patch power10-fix.patch.

- Add power10 fix power10-fix.patch for #1142.

• Files Changed
• Browse Source

- Update to version 2.3.2
  * Remove upstream patch fix-arm.patch.
  * mold no longer emits dynamic relocations against the text segment for GNU ifunc
    symbols. Previously, mold emitted such relocations for position-dependent
    executables. (4cdfc7e)
  * mold no longer reports the "REL-type relocation table is not supported for this
    target" error and instead ignore incompatible relocation tables. LLVM generates
    such non-conforming relocation tables for the .llvm.call-graph-profile section.
    This change was made for compatibility. (3791900)
  * mold now pads unused gaps in the text segment with interrupt or NOP
    instructions, instead of leaving them filled with zeros. This alteration does
    not change the program's semantics but prevents disassemblers from interpreting
    the spaces between functions as valid instructions. (c86a59a)
  * mold now creates the .mold-lock file for MOLD_JOBS not in the home directory but
    in $XDG_RUNTIME_DIR, which is usually /var/user/<uid>. (39cdf61)
  * [ARM32] There was an issue preventing mold from being built on an ARMv8 64-bit
    ARM processor with an ARM32 userland, such as the 32-bit Raspberry Pi OS running
    on a Raspberry Pi 4. This build issue has been resolved. (02ead29)
  * [LoongArch] mold can now handle R_LARCH_PCALA_LO12 relocation for the jirl
    instruction. (d3188e3)

• Files Changed
• Browse Source

- Add fix-arm.patch in order to fix failing arm-arm_range-extension-thunk2 test.

• Files Changed
• Browse Source

- Update to version 2.3.1
  * [ARM32, ARM64, PowerPC, LoongArch] mold 2.3.0 would crash when handling large
    output files. This was due to a bug in the code that creates range extension
    thunks. This issue has now been resolved. (7be1b66)
  * [LoongArch] mold is now capable of handling relocations generated for the
    -mcmodel=extreme flag. (4bd80ec)

• Files Changed
• Browse Source

- Update to version 2.3.0
  * [x86-64] mold 2.3.0 has introduced an experimental flag, -z rewrite-endbr, which
    rewrites superfluous endbr64 instructions as nop.
  * endbr64 is a relatively recent x86 instruction used to mark locations where an
    indirect jump instruction can transfer control. With control-flow integrity
    enabled (meaning endbr64 is effective), an indirect jump can only target an
    endbr64 or it will trigger a runtime exception. This mechanism significantly
    hinders certain control hijacking attacks, such as ROP or JOP, since attackers
    cannot jump to just any location.
  * When given the -fcf-protection flag, GCC conservatively places an endbr64 at the
    beginning of every global function. This is because the function's address might
    be taken as a pointer by other translation units. However, in most cases,
    function addresses are not actually taken. This conservative approach results in
    an overabundance of unnecessary endbr64 instructions, leading to not only code
    bloating but also a potential decrease in security as there are more locations
    for an attacker to exploit.
  * The new linker option, -z rewrite-endbr, aims to alleviate this issue. The
    linker can carry out a whole-program analysis on the input files to identify
    functions whose addresses are never taken. If -z rewrite-endbr is specified,
    mold will conduct this analysis and replace the initial endbr64 with a nop for
    functions whose addresses aren't taken. (17f0d85)
  * mold now produces a more compact .gdb_index section when using the --gdb-index
    flag. Additionally, mold now generates a correct .gdb_index section for object
    files created by Clang. (a396fa4)
  * mold is now capable of handling input sections larger than 4 GiB. (0ce32d3)
  * [PPC] mold can now generate executables for POWER10 processors. Previously,
    executables produced by mold would crash immediately on startup on POWER10.
    (0f71471)
  * [ARM64] When a function with a non-standard calling convention is exported, it's
    mandatory for the linker to turn on the STO_AARCH64_VARIANT_PCS flag to notify

• Files Changed
• Browse Source

- Add build-blake-3-as-static.patch that builts BLAKE 3 support as static library
  into mold. The library is not provided in openSUSE yet.

- Update to version 2.2.0
  * We now use BLAKE3 as a cryptographic hash function instead of SHA256. This
    change has made --build-id a few percent faster. libssl is no longer a build
    dependency. (7f7a744)
  * mold is now a few percent faster than the previous version due to an
    optimization of string merging code path. (1a13c50)
  * mold now emits slightly optimized code for thread-local variable accesses.
    (f057fda, d56f528)
  * [RISC-V] mold now supports TLSDESC relocations. TLSDESC is a new mechanism for
    faster thread-local variable access. We (@ishitatsuyuki) actually led the effort
    to ratify the specification (riscv-non-isa/riscv-elf-psabi-doc#373) and
    implement it to compiler toolchain including GCC, GNU binutils and, of course,
    mold. (141556d)
  * mold no longer marks an as-needed .so as "needed" if the .so file is not
    directly used by the output file. Previously, mold marked a .so file as "needed"
    if the .so file was used by another "needed" .so file. (f02db0f)
  * [PPC64] --execute-only now works on 64-bit PowerPC. (ac20d87, 51fec5f)
- Remove openssl dependency.

• Files Changed
• Browse Source

- Update to version 2.1.0
  * Loongson's LoongArch CPU has been supported. (03b1a1c)
  * -z nosectionheader has been added to eliminate section headers from the output
    file. (084ca55)
  * Previously, linking with the -z pack-relative-relocs option produces an
    executable that glibc 2.38 refuses to run with DT_RELR without GLIBC_ABI_DT_RELR
    dependency error. Now, mold produces binaries compatible with glibc 2.38.
    (f467ad1)
  * [ARM64] R_AARCH64_ADR_PREL_PG_HI21_NC relocation type has been supported.
    (17a5c3e)
  * [ARM64] R_AARCH64_MOVW_UABS_G3 relocation type has now been handled as a
    PLT-generating relocation to fix an issue when main is not defined in the main
    executable but rather in a .so file. (e764557)
  * [RISC-V] We now merge input .riscv.attributes contents. Previously, we just
    concatenated them. (aa64491)

• Files Changed
• Browse Source

- Update to version 2.0.0
  * License changed to MIT.
  * Previously, mold could not produce an object file with more than 65520 sections
    using the --relocatable option. Now the bug has been fixed. (2e8bd0b)
  * mold now interprets -undefined as a synonym for --undefined instead of -u
    ndefined. This seems inconsistent, as -ufoo is generally treated as -u foo
    (which is an alias for --undefined foo), but this is the behavior of the GNU
    linkers and LLVM lld, so we prioritize compatibility over consistency.
  * -nopie is now handled as a synonym for --no-pie.
  * [RISC-V] R_RISCV_SET_ULEB128 and R_RISCV_SUB_ULEB128 relocation types are now
    supported (4bffe26, 1ac5fe7)
  * [PPC64] R_PPC64_REL32 relocation type is now supported. (ebd780e)

• Files Changed
• Browse Source

- Update to version 1.11.0
  * IBM Power10 has been supported. Previously, mold created broken executables for
    that target. (5065547)
  * --hash-style=none has been added to cancel --hash-style=sysv, --hash-style=gnu
    or --hash-style=both. (ec75633)
  * [ARM32] R_ARM_PLT32 relocation type has been supported. (e505900)
  * [RISC-V] R_RISCV_PLT32 relocation type has been supported. (51845ac)
  * Previous versions of mold failed to link some programs in rare corner cases if
    Link-Time Optimization (LTO) is enabled. These bugs have been fixed. (e1a7590,
    62d6537)
  * mold used to ignore dependencies between DSOs. Since this version, if a required
    DSO depends on other as-needed DSO, mold keeps the latter DSO as a required one.
    This improves compatibility with GNU linkers. (1adde7a)
  * [x86-64] mold can now link object files generated by old buggy versions of GCC.
    (d2970e0)
  * [x86-64] Previously, a program with a very large .bss section may fail to link
    due to R_X86_64_REX_GOTPCRELX relocation overflow (#975). This bug has been
    fixed. (627bf7c)

• Files Changed
• Browse Source

- Update to version 1.10.1
  * mold 1.10.0 had a buffer overrun bug that causes the linker to terminate
    immediately if compiled with -D_GLIBCXX_ASSERTIONS. We fixed the unsafe memory
    access in this release. (7e65546)

• Files Changed
• Browse Source

- Update to version 1.10.0
  * mold now officially supports the --print-dependencies option to print out
    dependency information between input files. Here is a truncated example output
    when linking mold itself with the option. There are many use cases of the
    option; for example, if you want to eliminate the dependency to some library
    from your program, you can use this option to find out all the functions that
    use the library's function to fix them. (6fd47db)
  * [x86-64][s390x] mold now optimizes thread-local variable accesses in shared
    libraries if the library is linked with -z nodlopen. If your shared library is
    not intended to be used via dlopen(2) and your library frequently accesses
    thread-local variables, you might want to pass that option when linking your
    library. (25d02bb, f32ce33)
  * [arm64] mold is now able to optimize GOT load by rewriting an ADDR+LDR
    instruction pair with an ADDR+ADD if the loaded GOT value is known at link-time.
    (f2311b1)
  * mold 1.9.0 was up to 10% slower than 1.8.0 on some multicore machines. We fixed
    the performance regression and made it even faster than 1.8.0. (7132822)
  * Previously, mold failed to report an undefined symbol error if there's a weak
    undefined symbol of the same name. That bug resulted in producing a non-working
    executable instead of reporting a link failure. Now, mold correctly reports such
    link errors. (8936194)
  * mold 1.9.0 might crash with SIGSEGV if --emit-relocs is used with object files
    containing debug info. That bug has been fixed. (e17d7da)

• Files Changed
• Browse Source

• Files Changed
• Browse Source

- Update to version 1.8.0
  * The --relocatable (or -r) option has been reimplemented to improve its
    performance and compatibility with the GNU linkers. That option tells the linker
    to combine input object files into another object file instead of into an
    executable or a shared library file. mold has been supporting the feature since
    version 0.9, but until now the output file created with -r looked fairly
    different from what GNU linkers would produce. GHC (Glasgow Haskell Compiler) in
    particular uses re-linkable object files as dynamic libraries instead of real
    .so files, and it didn't work with mold. Now, mold can produce object files that
    GHC can load. Note that this work was funded by Mercury, so thanks to the
    company to help us improve the product. (Yes, you can ask us to prioritize your
    feature request by funding the project.) (c9a7ae7)
  * --relocatable-merge-sections option has been added. By default, mold keeps
    original input section names for the --relocatable output and therefore does not
    merge input sections into a single output sections unless they are of the same
    name. If --relocatable-merge-sections is given, mold merges input by the usual
    default merging rule. For example, .text.foo and .text.bar are merged to .text
    if and only if --relocatable-merge-sections is given for the --relocatable
    output. (c2a0ae1)
  * -z [no]dynamic-undefined-weak options have been added. This option controls
    whether an undefined weak symbol is promoted to a dynamic symbol or not.
    (ed235f3)
  * --[no-]undefined-version options have been supported. Now, mold warns on a
    symbol name in a version script if it does not match with any defined symbol.
    This change was made so that it is easy to find a typo in a version script.
    (e2d7353)
  * mold now warns on symbol type mismatch. If two object files have the same symbol
    with different symbol types, it usually means your program has a bug. Chances
    are, you are using the same identifier as a function name in one translation
    unit and as a global variable name in another. So it makes sense to warn on the

• Files Changed
• Browse Source

- Update to version 1.7.1
  * mold 1.7.0 may generate the same build-id for two different output files. We
    fixed the issue in 1.7.1 so that build-id is guaranteed to be unique for each
    different output file. (d8dd124)

• Files Changed
• Browse Source

- Update to version 1.7.0
  * [m68k] mold now supports the Motorola 68000 series microprocessors. Yes, it's
    the processor in the original Mac or Sun workstations in the 80s. This work is
    sponsored by m68k hobbyist communities.
  * We fixed a few issues for Facebook/Meta's BOLT optimizer (#789). Starting from
    the next LLVM release (we need llvm/llvm-project@20204db), BOLT should work on
    mold-generated executables out of the box.
  * We fixed a long-standing symbol resolution issue involving GNU UNIQUE symbols
    which caused a link failure for a few programs. (730e970)
  * Previously, if a version script contains a "C++" directive, and a symbol matches
    a non-C++ version pattern and a C++ version pattern, a wrong version could be
    assigned to the symbol. This has been fixed so that the mold's behavior matches
    with GNU ld. (9875150)

• Files Changed
• Browse Source

- Update to version 1.6.0
  * [ppc64] mold now supports the original 64-bit big-endian PowerPC ABI (which is
    also known as PPC64 ELFv1 or just ppc64), so that you can build applications for
    older PPC64 systems with mold. Note that this should not be confused with the
    modern PPC64 ELFv2 ABI (which is also known as ppc64le), which is already
    supported by mold.
  * [s390x] Linux/s390x is now supported. Linux/s390x is the Linux environment
    running on IBM z/Architecture mainframes. I've personally never seen a
    mainframe, but we wanted to support it because many Linux distros actively
    support that target, which in turn means there are many enterprise users who are
    using IBM mainframes. Speaking of the porting effort, we do not only port our
    linker to s390x but also found a couple of issues with the existing GCC
    toolchain for s390x. So, we are improving the whole IBM mainframe ecosystem!
  * mold now creates smaller output files. It is most noticeable on targets with
    large page sizes such as PPC64 (on which the common page size is 64 KiB), but
    even on x86-64, it should save a few kilobytes per an output file.
  * [arm64] mold can now link executables with -static-pie. Previously, executables
    linked with that flag crashed immediately.
- Exclude ppc architecture as it is not supported right now.

• Files Changed
• Browse Source