8000 packages:mold: add version 2.38.1 by egtvedt · Pull Request #2346 · crosstool-ng/crosstool-ng · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

packages:mold: add version 2.38.1 #2346

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 7, 2025

Conversation

egtvedt
Copy link
Contributor
@egtvedt egtvedt commented Apr 29, 2025

Add newly released mold version 2.38.1 from upstream https://github.com/rui314/mold

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.

2.38.0
New Features

  • The --audit and --depaudit options are now supported for compatibility with GNU ld.

  • Recent versions of LLVM support an alternative, experimental relocation table format called CREL. mold can now read object files containing CREL relocation tables.

  • [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.

Bug Fixes and Compatibility Improvements

  • Previously, --no-allow-shlib-undefined could cause a segmentation fault due to an out-of-bounds array access. This has been fixed.

  • --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.

  • mold could report a spurious "duplicate symbol" error when performing LTO. This bug has been fixed.

  • In rare cases involving symbol versioning, mold mistakenly filtered out necessary libraries specified with --as-needed. This bug has been fixed.

  • In rare cases involving symbol versioning, mold reported a spurious "undefined symbol" error. This bug has been fixed.

  • 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 from the dynamic symbol table instead of exporting the default one (e.g., foo@@Version). This bug has been fixed.

Add newly released mold version 2.38.1 from upstream
https://github.com/rui314/mold

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.

2.38.0
New Features
- The --audit and --depaudit options are now supported for compatibility
  with GNU ld.

- Recent versions of LLVM support an alternative, experimental
  relocation table format called CREL. mold can now read object files
  containing CREL relocation tables.

- [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.

Bug Fixes and Compatibility Improvements
- Previously, --no-allow-shlib-undefined could cause a segmentation
  fault due to an out-of-bounds array access. This has been fixed.

- --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.

- mold could report a spurious "duplicate symbol" error when performing
  LTO. This bug has been fixed.

- In rare cases involving symbol versioning, mold mistakenly filtered
  out necessary libraries specified with --as-needed. This bug has been
  fixed.

- In rare cases involving symbol versioning, mold reported a spurious
  "undefined symbol" error. This bug has been fixed.

- 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 from the dynamic symbol table instead of
  exporting the default one (e.g., foo@@Version). This bug has been
  fixed.

Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
@cpackham cpackham force-pushed the mold-add-2.38.1 branch from b3f1ee6 to dcde305 Compare May 4, 2025 21:01
@cpackham cpackham merged commit 35c1e72 into crosstool-ng:master May 7, 2025
57 of 60 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0