Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Oct 2022 16:50:19 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 267201] devel/mold: update to 1.5.1
Message-ID:  <bug-267201-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267201

            Bug ID: 267201
           Summary: devel/mold: update to 1.5.1
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: ashish@FreeBSD.org
          Reporter: rozhuk.im@gmail.com
             Flags: maintainer-feedback?(ashish@FreeBSD.org)
          Assignee: ashish@FreeBSD.org

Created attachment 237461
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D237461&action=
=3Dedit
patch

mold 1.3.0

mold 1.3.0 is a new release of the high-speed linker. This release contains=
 a
few new features and general stability/compatibility improvements as shown
below.

Note for those who create mold binary packages: if you are building mold for
binary distribution, please link the bundled libtbb statically (which is
default) or rebuild your distro's libtbb package with my patch so that mold=
's
Link-Time Optimization (LTO) works reliably under a heavy load.
Bug fixes and compatibility improvements

    The --icf=3Dsafe option has been supported. This option enables a featu=
re to
find and deduplicate identical code that can be merged safely. For C++
programs, it typically reduces the output binary size by a few percent.
--icf=3Dsafe needs to be used with a compiler that supports .llvm_addrsig
section; if a compiler does not support it, --icf=3Dsafe doesn't do any har=
m but
cannot optimize a given program at all. That section is supported by LLVM/C=
lang
at the moment, and we are working on adding it to GCC. (#484, 27908af)
    LTO now works reliably under a heavy load. mold used to abort occasiona=
lly
under such condition on Linux due to a spurious failure of pthread_create(2=
).
(d8a8877)
    mold now prints out undefined symbol errors in a format similar to LLVM
lld. (13816a1)
    mold now prints out a better error message for the disk full situation.
(5969260)
    mold can now build GCC 12 with LTO. (708ad63)
    Fixed an LTO issue on 32-bits hosts such as i686. (920266b)
    mold is now AddressSanitizer and UndefinedSanitizer clean. (fafb75b,
3499ee6)
    mold used to create broken debug info on 32-bits hosts (#490). The bug =
has
been fixed. (0abd0a4)
    mold used to accept not only a single dash but also double dashes for
single-letter options. For example, --S was accidentally accepted as an ali=
as
for-S. This is unconventional, and such options are no longer accepted.
(232dafa)
    --color-diagnostics is now an alias for --color-diagnostics=3Dauto inst=
ead of
--color-diagnostics=3Dalways for compatibility with LLVM lld.
    pkg-config is no longer needed to build mold.
    The --package-metadata option is supported. (#505, e9f6715)

Removed features

    An experimental --preload flag has been removed. (a85b1f5)



mold 1.3.1

mold 1.3.1 is a maintenance release of the high-speed linker. This release
contains the following minor bug fixes.
Bug fixes and compatibility improvements

    mold now supports .preinit_array sections. Without this, AddressSanitiz=
er
didn't work in some environments. (3b75398)
    [ARM32] R_ARM_MOVT_PREL and R_ARM_PREL31 relocations are now handled
correctly so that mold no longer emit spurious "recompile with -fPIC" error=
s.
(5294300)




mold 1.4.0

mold 1.4.0 is a new release of the high-speed linker. This release contains=
 a
few new features and general stability/compatibility improvements as shown
below.

Note for those who create mold binary packages: if you are building mold for
binary distribution, please link the bundled libtbb statically (which is
default) or rebuild your distro's libtbb package with my patch so that mold=
's
Link-Time Optimization (LTO) works reliably under a heavy load.
New features

    Initial support for the 32-bit RISC-V (RV32) has landed. (d9db6bc)
    mold now demangles Rust symbols in error messages thanks to @eddyb's
rust-demangle.c. (22e1bba)
    --export-dynamic-symbol and --export-dynamic-symbol-list are now suppor=
ted
for the sake of compatibility with LLVM lld. With these options, you can
specify symbols that should be exported using glob pattern. (e115aae)
    [x86-64] PLT entries created by mold now always begins with ENDBR64
instruction to improve compatibility with Intel IBT (Indirect Branch Tracki=
ng.)
(e3e371d)

Bug fixes and compatibility improvements

    mold now defines __dso_handle symbol. The lack of this linker-synthesiz=
ed
symbol caused a link error with GCC in some environments (#507). (764d757)




mold 1.4.1

mold 1.4.1 is a maintenance release of the high-speed linker. This release
contains the following improvements and bug fixes.

Note for those who create mold binary packages: if you are building mold for
binary distribution, please link the bundled libtbb statically (which is
default) or rebuild your distro's libtbb package with my patch so that mold=
's
Link-Time Optimization (LTO) works reliably under heavy load.
New features

    mold/macOS is now available as an alpha feature. We do not recommend us=
ing
it for anything serious though. Starting from this version, we accept not o=
nly
mold/Unix issues but also mold/macOS ones on our GitHub Issues. Feel free to
file a bug if you encounter any problem.
    We started supporting CMake in addition to Make to build mold. Our
long-term plan is to migrate from Make to CMake because we want to support
Windows eventually and CMake provides a better Windows support than Make do=
es.
(e6a0e67)

Bug fixes and compatibility improvements

    There was a bug that mold accidentally exported a hidden symbol from an
executable if a shared library linked to that executable happened to define=
 the
same symbol. This caused a build issue with Blender (#606). The bug has been
fixed. (b163068)
    --hash-style=3Dboth is now the default if no --hash-style option is giv=
en.
Previously, --hash-style=3Dsysv was the default. This change shouldn't affe=
ct
most users because the compiler driver (cc, gcc, clang, etc.) always passes
--hash-style to the linker. We made this change because GNU ld defaults to
--hash-style=3Dboth.
    Alias symbols defined by the --defsym option now have the same scope as=
 the
aliased symbols. Previously, alias symbols defined by --defsym were always
hidden and never be exported as dynamic symbols. (5dd1227)
    mold now accepts foo =3D bar-style linker script directive to define sy=
mbol
aliases. Previously, such statement was treated as a syntax error. This cha=
nge
was made to link mariadb-connector-c correctly (f0e1237)
    Symbols in mergeable string sections now have correct output section
indices instead of SHN_UNDEF. (a595c48)
    [ARM32] Previously, calling a function from ARM code to Thumb code caus=
ed a
program crash due to bug #442. This issue has been fixed. (053b90b)




mold 1.4.2

mold 1.4.2 is a maintenance release of the high-speed linker. This release
includes, but not limited to, the following improvements and bug fixes.

Note for those who create mold binary packages: if you are building mold for
binary distribution, please link the bundled libtbb statically (which is
default) or rebuild your distro's libtbb package with my patch so that mold=
's
Link-Time Optimization (LTO) works reliably under heavy load.
New features and bug fixes

    [RV32] We've fixed several issues for 32-bit RISC-V. mold can now build
complex programs including itself for the target.
    [ARM32] mold gained range extension thunks so that it can now link prog=
rams
whose .text is larger than 16 MiB. Previously, mold couldn't link such large
programs. We've also fixed general stability issues for ARM32.




mold 1.5.0

mold 1.5.0 is a new release of the high-speed linker. The highlight of this
release is that we start supporting the following four new targets: PPC64LE,
SPARC64, RV32BE and RV64BE. mold 1.5.0 also includes various bug fixes,
performance and compatibility improvements as shown below.

Starting from this release, we recommend using cmake instead of make to bui=
ld
mold. We will soon stop supporting make, so please migrate early and report
issues if you find any.

Note for those who create mold binary packages: if you are building mold for
binary distribution, please link the bundled libtbb statically (which is
default) or rebuild your distro's libtbb package with my patch so that mold=
's
Link-Time Optimization (LTO) works reliably under heavy load.
New features

    PPC64LE and SPARC64 are now supported as new targets. They haven't yet =
been
as well tested as other targets, but they are already able to link mold its=
elf
on these platforms. (Note that PPC64LE is very unlikely to work on the most
recent POWER10 machines as we didn't have a chance to test it due to a limi=
ted
availability (POWER10 was released in 2021). If you can support us on this
matter, please contact us. We also accept donations, so please consider
supporting our project!)
    RV32BE and RV64BE (32-bit and 64-bit big-endian RISC-V) are now support=
ed
as experimental targets. RISC-V is usually little-endian, but there exists a
big-endian RISC-V as an extension. You can make gcc to emit code for big-en=
dian
RISC-V by passing -mbig-endian. mold can now link object files generated wi=
th
that option.
    --compress-debug-sections=3Dzstd is now supported. This is an option to
compress debug info embedded to an output file with Zstandard compression
algorithm. Compared to the existing --compress-debug-sections=3Dzlib, zstd =
is
faster and gives a higher compression ratio. You probably can't start using
zstd compression today though, because other tools such as gdb may not be a=
ble
to read zstd-compressed debug info yet. But adding this option early makes =
mold
future-proof. (ede7a5a)
    mold no longer aligns loadable segments to page boundaries to reduce ou=
tput
file size. Previously, we allocated holes between loadable segments. The sa=
ving
by this change is most visible for small programs. For example, a "hello wo=
rld"
program used to be ~18 KiB on x86-64. It's now 7.2 KiB. (2941d75)

Bug fixes and compatibility improvements

    [RISCV] We optimized code so that the link speed for RISC-V is now
comparable to the other targets. As an example, linking mold itself (~150 M=
iB
in size) for RV64 used to take ~45 seconds on a simulated 16-core machine. =
It
now takes only ~0.25 seconds. (3ab5489)
    mold used to create more than one .rodata section under a certain
condition. It's not technically wrong but confused Valgrind. This issue has
been resolved. (25c7aee)
    [ARM32] Previously, mold failed to promote remaining undefined symbols =
to
dynamic symbols if symbols are undefined weak. That caused a link failure f=
or
libxml (#660). This issue has been resolved. (72e26d9)
    mold didn't copy symbol types when creating symbol aliases for the --de=
fsym
option. (8c7f31c)

Removed features

    --compress-debug-sections=3Dzlib-gnu has been removed. LLVM lld removed=
 that
option too as there seems to be no usage of the flag.




mold 1.5.1

mold 1.5.1 is a new release of the high-speed linker. This version contains
only the following bug fix. We recommend upgrading from 1.5.0 if you are be=
ing
affected by this issue.

    We changed the memory layout to save both memory and disk space in 1.5.=
0.
Even though the new layout works fine on most systems, the change made the
linker to create unusable executables for systems with large pages.
Specifically, if you specify a large number for the -z max-page-size option,
the loader refused to execute it with the error while loading shared librar=
ies:
cannot apply additional memory protection after relocation: Cannot allocate
memory error. We reverted our recent commits so that mold creates output fi=
les
with the same memory layout as it did before 1.5.0. (e62de0b)

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-267201-7788>