From nobody Wed Oct 19 16:50:19 2022 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsxYR3k3kz4gPKY for ; Wed, 19 Oct 2022 16:50:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsxYR0lMCz3fdP for ; Wed, 19 Oct 2022 16:50:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4MsxYQ6r0yzbCy for ; Wed, 19 Oct 2022 16:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 29JGoIAg089293 for ; Wed, 19 Oct 2022 16:50:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 29JGoIOi089291 for ports-bugs@FreeBSD.org; Wed, 19 Oct 2022 16:50:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 267201] devel/mold: update to 1.5.1 Date: Wed, 19 Oct 2022 16:50:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ashish@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter flagtypes.name attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666198219; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=OHTOUuhCx6W4Pi2sgmwmCfFgV5JIqgWPKy/X3tx8Nu4=; b=p3JWuzuZTQrJCrS4Rh5kh445CJncfToQboRPUJyPZ4K6NjZim4oHDs6+SLbhL1iGt00uIB 6+W87/2CPvX11wIAwRz242TH3nu3NaYkB+1HMbm5FQDO+YJ6am5/6vwsy/iibUK1Fg9WKG bkOcgu7Z4eY/60HrC1+vPpwr9Fc+gWSCj8AwkJPB/vOqBr4sZ46y6Ri5tseIIW6DdtGX5a gtsfVVUOg/gHzVasSkRfUV8YB2ANj5prPzzJoQF5TdZY5Dt00+SwVfu5mQwjAG//VBxvPG mirlUwCHklY0a1ueKJapA27kQL6VbAGqglPpIW79hMqW/f1tQoFAtnmVAso9qA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666198219; a=rsa-sha256; cv=none; b=mnYKWQ3r9RgFYPTyuUT+K+MxDs8KSrQ9F/ktW6DwV91hrwVGs8pL1EYjEEC3bnf8u6MyCB 66XWxIu/s5M4JQuR9n/FytQAaXwZbA695qTwdoZOiJvnW3kUivS+i6tZV+qr8nfcEbiFX1 J4NTgIwvq+0PUDFGUHWhCeYQv9Mc1Fbu74fwX95Lvr07VfiRWHmZYbmbJZS/6963QmWYLJ O81E1EwScsOpl/kkXIyzIKgUJ7uZRpka7BPuPS8XYDlKfAqTubxfiI6UhjJk63KNS7UYQP A1qy3v394H8BNaJMtCMUAFj4As5uW83TeGc123ho8EaLP958MHmgVBDhTg4fkA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N 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.=