- Update to version 2.40.1
* We've eliminated unnecessary memory zero-initialization for the
--compress-debug-sections option to make debug section compression faster. With
this change, mold sometimes runs faster with --compress-debug-sections than
without it due to reduced file I/O. (d59c559)
* Previously, mold used an exponential pattern-matching algorithm for glob
matching, which could significantly slow down version scripts or dynamic list
processing for certain glob patterns. Now, we use a linear-time algorithm that
is guaranteed to run efficiently for any glob pattern. (dac20fa)
* mold now reports an error if the output .dynsym refers to a section whose
section index is ≥65280, since such a dynamic symbol is not representable in
ELF. Previously, mold crashed with an assertion failure. (0d8334e)
OBS-URL: https://build.opensuse.org/request/show/1283993
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/mold?expand=0&rev=60
* We've eliminated unnecessary memory zero-initialization for the
--compress-debug-sections option to make debug section compression faster. With
this change, mold sometimes runs faster with --compress-debug-sections than
without it due to reduced file I/O. (d59c559)
* Previously, mold used an exponential pattern-matching algorithm for glob
matching, which could significantly slow down version scripts or dynamic list
processing for certain glob patterns. Now, we use a linear-time algorithm that
is guaranteed to run efficiently for any glob pattern. (dac20fa)
* mold now reports an error if the output .dynsym refers to a section whose
section index is ≥65280, since such a dynamic symbol is not representable in
ELF. Previously, mold crashed with an assertion failure. (0d8334e)
OBS-URL: https://build.opensuse.org/package/show/devel:tools:compiler/mold?expand=0&rev=154
- Update to version 2.40.0
* mold now lays out DWARF32 debug info before DWARF64 in output debug sections to
mitigate relocation overflow issues with DWARF32 when a debug info section
exceeds 4 GiB. This should help people who are building extremely large
executables in debug mode. (19a1bc6, 159ce3b)
* Here are the details: By default, GCC and Clang emit DWARF32 even for 64-bit
code. That is, the debug info typically uses 32 bit offsets to refer to
locations in other debug info sections while it uses 64 bits to represent
addresses. This imposes a limitation on the largest offset DWARF32 debug info
can refer to, which is 4 GiB. If the output debug section exceeds that size, the
linker may report a relocation overflow error. You can instruct the compilers to
emit DWARF64, which uses 64 bits for inter-debug info references, if you are
building an extremely large executable. So, the proper fix for the relocation
overflow issue is to build all object files with -gdwarf64. However, rebuilding
all static libraries with the new compiler flag is not always feasible for
various reasons. This new feature mitigates the issue by placing DWARF32 at the
beginning of output debug info sections, followed by DWARF64. By doing so,
relocation overflow can be prevented as long as the total size of DWARF32
remains under 4 GiB, allowing users to continue using object files compiled
without -gdwarf64 for very large executables.
* Note that mold only sorts debug section contents when their size exceeds 4 GiB.
Therefore, for most outputs, this mitigation doesn't change the result at all.
* Fixed a regression introduced in 2.38.0 in which a thread-local variable with an
unusually large alignment might not have been aligned properly. That caused
mislinking of systemd when LTO was enabled (#1463). (53c1758)
* Fixed a regression introduced in 2.38.0 in which --as-needed was ignored when
creating an executable under a rare condition. (af36625)
* Fixed an assertion failure on some targets that is triggered when an weak
undefined symbol in an executable is promoted to a dynamic symbol with the -z
dynamic-undefined-weak option. (0fdffad)
OBS-URL: https://build.opensuse.org/request/show/1279984
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/mold?expand=0&rev=59
* mold now lays out DWARF32 debug info before DWARF64 in output debug sections to
mitigate relocation overflow issues with DWARF32 when a debug info section
exceeds 4 GiB. This should help people who are building extremely large
executables in debug mode. (19a1bc6, 159ce3b)
* Here are the details: By default, GCC and Clang emit DWARF32 even for 64-bit
code. That is, the debug info typically uses 32 bit offsets to refer to
locations in other debug info sections while it uses 64 bits to represent
addresses. This imposes a limitation on the largest offset DWARF32 debug info
can refer to, which is 4 GiB. If the output debug section exceeds that size, the
linker may report a relocation overflow error. You can instruct the compilers to
emit DWARF64, which uses 64 bits for inter-debug info references, if you are
building an extremely large executable. So, the proper fix for the relocation
overflow issue is to build all object files with -gdwarf64. However, rebuilding
all static libraries with the new compiler flag is not always feasible for
various reasons. This new feature mitigates the issue by placing DWARF32 at the
beginning of output debug info sections, followed by DWARF64. By doing so,
relocation overflow can be prevented as long as the total size of DWARF32
remains under 4 GiB, allowing users to continue using object files compiled
without -gdwarf64 for very large executables.
* Note that mold only sorts debug section contents when their size exceeds 4 GiB.
Therefore, for most outputs, this mitigation doesn't change the result at all.
* Fixed a regression introduced in 2.38.0 in which a thread-local variable with an
unusually large alignment might not have been aligned properly. That caused
mislinking of systemd when LTO was enabled (#1463). (53c1758)
* Fixed a regression introduced in 2.38.0 in which --as-needed was ignored when
creating an executable under a rare condition. (af36625)
* Fixed an assertion failure on some targets that is triggered when an weak
undefined symbol in an executable is promoted to a dynamic symbol with the -z
dynamic-undefined-weak option. (0fdffad)
OBS-URL: https://build.opensuse.org/package/show/devel:tools:compiler/mold?expand=0&rev=152
- Update to version 2.39.0
* [ARM32] Support for 32-bit big-endian ARM has been added. Although running ARM32
in big-endian mode is very rare, the processor does technically support both
little- and big-endian modes, and we now support both.
* There are two variants of big-endian mode for ARM32: BE32 and BE8. BE32 is now
obsolete and uses big-endian format for both instructions and data. In BE8,
instructions are always in little-endian (i.e., the same as little-endian
ARM32), while only the data is in big-endian. mold supports only BE8 output.
(157b16a)
* Fixed a spurious --no-allow-shlib-undefined error. (3274bcb)
* [ARM][PPC] Fixed a regression introduced in 2.38.0 that mold could crash when
linking a large program. (fded2d8)
* Previously, --default-symver didn't set versions to symbols if the symbols were
marked as global: in a version script. Now, --default-symver correctly version
all symbols with the soname of the output file. (8bae43b)
* [RISC-V] Fixed an issue where mold reported an error on R_RISCV_32 when the
target was 64-bit RISC-V. (564757a)
* [RISC-V] Fixed an issue where a call to an weak undefined symbol within the same
shared library was mistakenly turned into an infinite loop. Now, such calls are
promoted to a function call through the PLT entry. (e08e7f6)
* Fixed an issue that mold falls into an infinite loop in a rare occasion when
computing an address of the program header. (83dd353)
OBS-URL: https://build.opensuse.org/request/show/1274689
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/mold?expand=0&rev=57
* [ARM32] Support for 32-bit big-endian ARM has been added. Although running ARM32
in big-endian mode is very rare, the processor does technically support both
little- and big-endian modes, and we now support both.
* There are two variants of big-endian mode for ARM32: BE32 and BE8. BE32 is now
obsolete and uses big-endian format for both instructions and data. In BE8,
instructions are always in little-endian (i.e., the same as little-endian
ARM32), while only the data is in big-endian. mold supports only BE8 output.
(157b16a)
* Fixed a spurious --no-allow-shlib-undefined error. (3274bcb)
* [ARM][PPC] Fixed a regression introduced in 2.38.0 that mold could crash when
linking a large program. (fded2d8)
* Previously, --default-symver didn't set versions to symbols if the symbols were
marked as global: in a version script. Now, --default-symver correctly version
all symbols with the soname of the output file. (8bae43b)
* [RISC-V] Fixed an issue where mold reported an error on R_RISCV_32 when the
target was 64-bit RISC-V. (564757a)
* [RISC-V] Fixed an issue where a call to an weak undefined symbol within the same
shared library was mistakenly turned into an infinite loop. Now, such calls are
promoted to a function call through the PLT entry. (e08e7f6)
* Fixed an issue that mold falls into an infinite loop in a rare occasion when
computing an address of the program header. (83dd353)
OBS-URL: https://build.opensuse.org/package/show/devel:tools:compiler/mold?expand=0&rev=148
- Update to version 2.38.1
* Fixed a bug where mold could fail with a spurious mutually-recursive .so
detected error message when building an executable. This happened if there was a
circular dependency between shared libraries given to the linker (i.e.,
libfoo.so depends on libbar.so and vice versa). Even though libraries with
circular dependencies are rare and a strong indication of a bug in the original
program's library layering, the dynamic loader can load such libraries, and the
linker shouldn't reject them. (21e20e0)
OBS-URL: https://build.opensuse.org/request/show/1273270
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/mold?expand=0&rev=56
* Fixed a bug where mold could fail with a spurious mutually-recursive .so
detected error message when building an executable. This happened if there was a
circular dependency between shared libraries given to the linker (i.e.,
libfoo.so depends on libbar.so and vice versa). Even though libraries with
circular dependencies are rare and a strong indication of a bug in the original
program's library layering, the dynamic loader can load such libraries, and the
linker shouldn't reject them. (21e20e0)
OBS-URL: https://build.opensuse.org/package/show/devel:tools:compiler/mold?expand=0&rev=146
- Update to version 2.38.0
* The --audit and --depaudit options are now supported for compatibility with GNU
ld. (af396ad)
* Recent versions of LLVM support an alternative, experimental relocation table
format called CREL. mold can now read object files containing CREL relocation
tables. (c43a859)
* [ARM32][ARM64][PPC32][PPC64] The branch instruction ranges of RISC processors
are generally insufficient to support the medium code model because their
instructions are typically 32 bits long, which makes it impossible to embed
large immediate offsets. For example, ARM64’s branch instruction can target only
PC ± 128 MiB. If the branch target is farther than that, the linker must emit a
small piece of code—often called a thunk or branch island—to extend the branch
range.
* Previously, mold created unnecessary range extension thunks for symbols that had
PLT entries. Now, mold does not create thunks unless they are truly needed.
(a43f395)
* Previously, --no-allow-shlib-undefined could cause a segmentation fault due to
an out-of-bounds array access. This has been fixed. (82affb9)
* --no-allow-shlib-undefined is enabled by default if the output type is an
executable (as opposed to a shared library) for compatibility with other
linkers. (43810df)
* mold could report a spurious "duplicate symbol" error when performing LTO. This
bug has been fixed. (5d24db5)
* In rare cases involving symbol versioning, mold mistakenly filtered out
necessary libraries specified with --as-needed. This bug has been fixed.
(a97a628)
* In rare cases involving symbol versioning, mold reported a spurious "undefined
symbol" error. This bug has been fixed. (2d6061a)
* If the same symbol was defined with and without the default version (e.g., if an
object file defined both foo and foo@@VERSION), mold mistakenly hid both symbols
OBS-URL: https://build.opensuse.org/request/show/1272922
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/mold?expand=0&rev=55
* The --audit and --depaudit options are now supported for compatibility with GNU
ld. (af396ad)
* Recent versions of LLVM support an alternative, experimental relocation table
format called CREL. mold can now read object files containing CREL relocation
tables. (c43a859)
* [ARM32][ARM64][PPC32][PPC64] The branch instruction ranges of RISC processors
are generally insufficient to support the medium code model because their
instructions are typically 32 bits long, which makes it impossible to embed
large immediate offsets. For example, ARM64’s branch instruction can target only
PC ± 128 MiB. If the branch target is farther than that, the linker must emit a
small piece of code—often called a thunk or branch island—to extend the branch
range.
* Previously, mold created unnecessary range extension thunks for symbols that had
PLT entries. Now, mold does not create thunks unless they are truly needed.
(a43f395)
* Previously, --no-allow-shlib-undefined could cause a segmentation fault due to
an out-of-bounds array access. This has been fixed. (82affb9)
* --no-allow-shlib-undefined is enabled by default if the output type is an
executable (as opposed to a shared library) for compatibility with other
linkers. (43810df)
* mold could report a spurious "duplicate symbol" error when performing LTO. This
bug has been fixed. (5d24db5)
* In rare cases involving symbol versioning, mold mistakenly filtered out
necessary libraries specified with --as-needed. This bug has been fixed.
(a97a628)
* In rare cases involving symbol versioning, mold reported a spurious "undefined
symbol" error. This bug has been fixed. (2d6061a)
* If the same symbol was defined with and without the default version (e.g., if an
object file defined both foo and foo@@VERSION), mold mistakenly hid both symbols
OBS-URL: https://build.opensuse.org/package/show/devel:tools:compiler/mold?expand=0&rev=144
- Update to version 2.37.0
* If an undefined weak symbol is not resolved to a defined symbol at link time,
the linker can choose whether to promote the symbol to a dynamic symbol or not.
If promoted, the weak symbol has another chance to be resolved to a defined
symbol at load time. Otherwise, it is resolved to address 0 at link time.
Previously, mold always resolved remaining undefined weak symbols in an
executable to address 0 at link time. Now, you can instruct the linker to
promote them to dynamic symbols using -z dynamic-undefined-weak. (1822e47)
* [x86-64] The relocation types
R_X86_64_CODE_4_{GOTPCRELX,GOTTPOFF,GOTPC32_TLSDESC} and
R_X86_64_CODE_6_GOTTPOFF are now supported. These relocations are for Intel APX
(Advanced Performance Extensions), which extends the number of general-purpose
registers from 16 to 32. (83152ac, a17202d)
* [ARM32] The R_ARM_THM_JUMP8 relocation type is now supported. (1fbbcec)
* [ARM32] Previously, the .ARM.exidx section (which contains exception-handling
records) was not subject to garbage collection, even when --gc-sections was
specified. This prevented all functions from being garbage-collected, as they
were referenced by exception-handling records. Now, mold correctly
garbage-collects unused .ARM.exidx records and functions. (16f7599)
* Previously, --compress-debug-sections was ignored if --separate-debug-file was
specified. Now, mold compresses debug information sections even when they are in
a separate debug file. (bab7dd1)
OBS-URL: https://build.opensuse.org/request/show/1250569
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/mold?expand=0&rev=52
* If an undefined weak symbol is not resolved to a defined symbol at link time,
the linker can choose whether to promote the symbol to a dynamic symbol or not.
If promoted, the weak symbol has another chance to be resolved to a defined
symbol at load time. Otherwise, it is resolved to address 0 at link time.
Previously, mold always resolved remaining undefined weak symbols in an
executable to address 0 at link time. Now, you can instruct the linker to
promote them to dynamic symbols using -z dynamic-undefined-weak. (1822e47)
* [x86-64] The relocation types
R_X86_64_CODE_4_{GOTPCRELX,GOTTPOFF,GOTPC32_TLSDESC} and
R_X86_64_CODE_6_GOTTPOFF are now supported. These relocations are for Intel APX
(Advanced Performance Extensions), which extends the number of general-purpose
registers from 16 to 32. (83152ac, a17202d)
* [ARM32] The R_ARM_THM_JUMP8 relocation type is now supported. (1fbbcec)
* [ARM32] Previously, the .ARM.exidx section (which contains exception-handling
records) was not subject to garbage collection, even when --gc-sections was
specified. This prevented all functions from being garbage-collected, as they
were referenced by exception-handling records. Now, mold correctly
garbage-collects unused .ARM.exidx records and functions. (16f7599)
* Previously, --compress-debug-sections was ignored if --separate-debug-file was
specified. Now, mold compresses debug information sections even when they are in
a separate debug file. (bab7dd1)
OBS-URL: https://build.opensuse.org/package/show/devel:tools:compiler/mold?expand=0&rev=138
- Update to version 2.36.0
* The --package-metadata=<string> option has been added to embed a given string
into the .note.package section. This option is designed for build scripts that
generate binary packages, such as .rpm or .deb, to include package metadata in
each executable. It simplifies the process of identifying the corresponding
package for a given executable or core file. (7ddc8f4)
* [ARM][PowerPC] We've improved the algorithm for creating range extension thunks
to reduce memory usage and improve speed. For example, linking clang-19 for
ARM64 is now ~7% faster than before. (9fc0ace)
* [RISC-V][LoongArch] We've improved the algorithm for code-shrinking linker
relaxation to reduce memory usage and improve speed. For example, linking
clang-19 for RISC-V is now ~4% faster than before. (3234d88)
* mold created a bad relocation for an IFUNC if the linker's output file type was
a shared library and the symbol was exported. This bug could cause a
segmentation fault of a linked program. The problem has now been fixed.
(a297859)
* [RISC-V] mold could produce incorrect code as a result of code-shrinking
relaxation for the R_RISCV_HI20 relocation. That type of relocation was used
rarely because it is not PC-relative. That being said, if your program used the
relocation, and the relocation targets were at a low address (from 0x1f800 to
0x20000), your program would crash at runtime due to the linker's bug. The issue
has now been resolved. (eec3f6b)
* [RISC-V][LoongArch] When the linker removed instructions from a function as a
result of code-shrinking relaxation, the function symbol's size in the output
file should be updated to reflect the result of relaxation, even though doing it
is mostly cosmetic. mold did not do that. Now, mold sets correct sizes to output
function symbols. (e6345d5)
* [LoongArch] Binaries linked with mold now work on 64 KiB page systems.
Previously, only up to 16 KiB pages were supported. (2d7b6b2)
* [s390x] The s390x processor-specific ABI requires the linker to reserve the
OBS-URL: https://build.opensuse.org/request/show/1236113
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/mold?expand=0&rev=51
* The --package-metadata=<string> option has been added to embed a given string
into the .note.package section. This option is designed for build scripts that
generate binary packages, such as .rpm or .deb, to include package metadata in
each executable. It simplifies the process of identifying the corresponding
package for a given executable or core file. (7ddc8f4)
* [ARM][PowerPC] We've improved the algorithm for creating range extension thunks
to reduce memory usage and improve speed. For example, linking clang-19 for
ARM64 is now ~7% faster than before. (9fc0ace)
* [RISC-V][LoongArch] We've improved the algorithm for code-shrinking linker
relaxation to reduce memory usage and improve speed. For example, linking
clang-19 for RISC-V is now ~4% faster than before. (3234d88)
* mold created a bad relocation for an IFUNC if the linker's output file type was
a shared library and the symbol was exported. This bug could cause a
segmentation fault of a linked program. The problem has now been fixed.
(a297859)
* [RISC-V] mold could produce incorrect code as a result of code-shrinking
relaxation for the R_RISCV_HI20 relocation. That type of relocation was used
rarely because it is not PC-relative. That being said, if your program used the
relocation, and the relocation targets were at a low address (from 0x1f800 to
0x20000), your program would crash at runtime due to the linker's bug. The issue
has now been resolved. (eec3f6b)
* [RISC-V][LoongArch] When the linker removed instructions from a function as a
result of code-shrinking relaxation, the function symbol's size in the output
file should be updated to reflect the result of relaxation, even though doing it
is mostly cosmetic. mold did not do that. Now, mold sets correct sizes to output
function symbols. (e6345d5)
* [LoongArch] Binaries linked with mold now work on 64 KiB page systems.
Previously, only up to 16 KiB pages were supported. (2d7b6b2)
* [s390x] The s390x processor-specific ABI requires the linker to reserve the
OBS-URL: https://build.opensuse.org/package/show/devel:tools:compiler/mold?expand=0&rev=136
- Update to version 2.35.1
* mold guarantees that outputs are reproducible, meaning that if you provide the
exact same set of input files and command-line options to the same version of
mold, the output is assured to be byte-for-byte identical. However, there was a
bug where the --icf option caused outputs to be indeterministic, even though all
possible outputs were logically correct (#1377). This issue has now been
resolved. (2a78b1b)
* [RISC-V] Support for obsolete GP-relative relocations has been removed. These
relocations were ratified (riscv-non-isa/riscv-elf-psabi-doc@d49e480) but then
removed (riscv-non-isa/riscv-elf-psabi-doc@ad02546) from the processor-specific
ABI. There are no known real-world use cases for these relocations. (04066d1)
OBS-URL: https://build.opensuse.org/request/show/1231732
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/mold?expand=0&rev=50
* mold guarantees that outputs are reproducible, meaning that if you provide the
exact same set of input files and command-line options to the same version of
mold, the output is assured to be byte-for-byte identical. However, there was a
bug where the --icf option caused outputs to be indeterministic, even though all
possible outputs were logically correct (#1377). This issue has now been
resolved. (2a78b1b)
* [RISC-V] Support for obsolete GP-relative relocations has been removed. These
relocations were ratified (riscv-non-isa/riscv-elf-psabi-doc@d49e480) but then
removed (riscv-non-isa/riscv-elf-psabi-doc@ad02546) from the processor-specific
ABI. There are no known real-world use cases for these relocations. (04066d1)
OBS-URL: https://build.opensuse.org/package/show/devel:tools:compiler/mold?expand=0&rev=134
- Update to version 2.35.0
* Big-endian ARM64 is now supported. ARM64 is a bi-endian processor, meaning that
the processor can run in either little- or big-endian mode. Even though
little-endian is the de facto standard, the ARM64 processor-specific ABI defines
its big-endian variant, and the ARM toolchain supports it. Now we support it
too. (882e7eb)
* Big-endian SH4 is now supported. SH4 has become a minor CPU nowadays, and its
big-endian variant is even more so, but some SHARP scientific calculators still
use SH4 processors in big-endian mode. (0cb9fc6)
* mold attempts to overwrite an existing file if a specified output file already
exists because reusing an existing file is much faster than creating a fresh
file and writing to it on Linux. If an existing file is currently running,
open(2) for that file fails with ETXTBSY. When that happens, mold falls back to
creating a new file. The problem here is that Linux kernel version 6.11 changed
that well-known behavior of open(2), and it now allows user programs to
overwrite a running executable. That caused a very mysterious issue for programs
that rebuild themselves during the build, such as gcc or ninja (#1361). Even
though the kernel's change has been reverted (torvalds/linux@3b83203), we need
to make adjustments to mold for that particular version of the Linux kernel. So,
if mold detects that it is running on Linux 6.11, it no longer tries to reuse an
existing output file. (8e4f7b5)
* On rare occasions, mold could fail with a "ConcurrentMap is full" error. Now the
issue has been resolved. (e56b649)
* Even if a user choose not to use mimalloc memory allocator (i.e. built mold with
-DMOLD_USE_MIMALLOC=0), mold was still being built with mimalloc. This issue has
been resolved. (ffd10dd)
* [s390x] s390x uses nonstandard 8-byte entries for the .hash section. Previously,
mold created 4-byte entries for .hash, which caused mold-generated executables
to crash on startup if they were built with -Wl,--hash-style=sysv. Now, mold
generates a psABI-compliant .hash section. (e2e1146)
OBS-URL: https://build.opensuse.org/request/show/1229097
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/mold?expand=0&rev=49
* Big-endian ARM64 is now supported. ARM64 is a bi-endian processor, meaning that
the processor can run in either little- or big-endian mode. Even though
little-endian is the de facto standard, the ARM64 processor-specific ABI defines
its big-endian variant, and the ARM toolchain supports it. Now we support it
too. (882e7eb)
* Big-endian SH4 is now supported. SH4 has become a minor CPU nowadays, and its
big-endian variant is even more so, but some SHARP scientific calculators still
use SH4 processors in big-endian mode. (0cb9fc6)
* mold attempts to overwrite an existing file if a specified output file already
exists because reusing an existing file is much faster than creating a fresh
file and writing to it on Linux. If an existing file is currently running,
open(2) for that file fails with ETXTBSY. When that happens, mold falls back to
creating a new file. The problem here is that Linux kernel version 6.11 changed
that well-known behavior of open(2), and it now allows user programs to
overwrite a running executable. That caused a very mysterious issue for programs
that rebuild themselves during the build, such as gcc or ninja (#1361). Even
though the kernel's change has been reverted (torvalds/linux@3b83203), we need
to make adjustments to mold for that particular version of the Linux kernel. So,
if mold detects that it is running on Linux 6.11, it no longer tries to reuse an
existing output file. (8e4f7b5)
* On rare occasions, mold could fail with a "ConcurrentMap is full" error. Now the
issue has been resolved. (e56b649)
* Even if a user choose not to use mimalloc memory allocator (i.e. built mold with
-DMOLD_USE_MIMALLOC=0), mold was still being built with mimalloc. This issue has
been resolved. (ffd10dd)
* [s390x] s390x uses nonstandard 8-byte entries for the .hash section. Previously,
mold created 4-byte entries for .hash, which caused mold-generated executables
to crash on startup if they were built with -Wl,--hash-style=sysv. Now, mold
generates a psABI-compliant .hash section. (e2e1146)
OBS-URL: https://build.opensuse.org/package/show/devel:tools:compiler/mold?expand=0&rev=132
2024-12-08 08:59:14 +00:00
5 changed files with 268 additions and 9 deletions
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
@@ -17,7 +17,7 @@
Name:mold
Version:2.34.1
Version:2.40.1
Release:0
Summary:AModernLinker(mold)
License:MIT
@@ -81,6 +81,7 @@ export CXX=g++-11
%if %{suse_version} < 1550
exportTEST_CC=gcc-11
exportTEST_CXX=g++-11
exportTEST_GXX=g++-11
%endif
%ctest
@@ -110,6 +111,5 @@ fi
%{_mandir}/man1/ld.mold.1.gz
%dir%{_docdir}/mold
%doc%{_docdir}/mold/LICENSE
%doc%{_docdir}/mold/LICENSE.third-party
%changelog
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
