rustc will use rust-lld by default on x86_64-unknown-linux-gnu on nightly to significantly reduce linking times.rustc will use rust-lld by default on x86_64-unknown-linux-gnu on nightly to significantly reduce linking times.

rust-lld: How It Can Give You Faster Linking Times

4 min read

TL;DR: rustc will use rust-lld by default on x86_64-unknown-linux-gnu on nightly to significantly reduce linking times.

Some context

Linking time is often a big part of compilation time. When rustc needs to build a binary or a shared library, it will usually call the default linker installed on the system to do that (this can be changed on the command-line or by the target for which the code is compiled).

\ The linkers do an important job, with concerns about stability, backwards-compatibility and so on. For these and other reasons, on the most popular operating systems they usually are older programs, designed when computers only had a single core. So, they usually tend to be slow on a modern machine. For example, when building ripgrep 13 in debug mode on Linux, roughly half of the time is actually spent in the linker.

\ There are different linkers, however, and the usual advice to improve linking times is to use one of these newer and faster linkers, like LLVM's lld or Rui Ueyama's mold.

\ Some of Rust's wasm and aarch64 targets already use lld by default. When using rustup, rustc ships with a version of lld for this purpose. When CI builds LLVM to use in the compiler, it also builds the linker and packages it. It's referred to as rust-lld to avoid colliding with any lld already installed on the user's machine.

\ Since improvements to linking times are substantial, it would be a good default to use in the most popular targets. This has been discussed for a long time, for example in issues #39915 and #71515, and rustc already offers nightly flags to use rust-lld.

\ By now, we believe we've done all the internal testing that we could, on CI, crater, and our benchmarking infrastructure. We would now like to expand testing and gather real-world feedback and use-cases. Therefore, we will enable rust-lld to be the linker used by default on x86_64-unknown-linux-gnu for nightly builds.

Benefits

While this also enables the compiler to use more linker features in the future, the most immediate benefit is much improved linking times.

\ Here are more details from the ripgrep example mentioned above: linking is reduced 7x, resulting in a 40% reduction in end-to-end compilation times.

Before/after comparison of a ripgrep debug build

Most binaries should see some improvements here, but it's especially significant with e.g. bigger binaries, or when involving debuginfo. These usually see bottlenecks in the linker.

\ Here's a link to the complete results from our benchmarks.

\ If testing goes well, we can then stabilize using this faster linker by default for x86_64-unknown-linux-gnu users, before maybe looking at other targets.

Possible drawbacks

From our prior testing, we don't really expect issues to happen in practice. It is a drop-in replacement for the vast majority of cases, but lld is not bug-for-bug compatible with GNU ld.

\ In any case, using rust-lld can be disabled if any problem occurs: use the -Z linker-features=-lld flag to revert to using the system's default linker.

\ Some crates somehow relying on these differences could need additional link args. For example, we saw <20 crates in the crater run failing to link because of a different default about encapsulation symbols: these could require -Clink-arg=-Wl,-z,nostart-stop-gc to match the legacy GNU ld behavior.

\ Some of the big gains in performance come from parallelism, which could be undesirable in resource-constrained environments.

Summary

rustc will use rust-lld on x86_64-unknown-linux-gnu nightlies, for much improved linking times, starting in tomorrow's rustup nightly (nightly-2024-05-18). Let us know if you encounter problems, by opening an issue on GitHub.

\ If that happens, you can revert to the default linker with the -Z linker-features=-lld flag. Either by adding it to the usual RUSTFLAGS environment variable, or to a project's .cargo/config.toml configuration file, like so:

[target.x86_64-unknown-linux-gnu] rustflags = ["-Zlinker-features=-lld"] 

Rémy Rakic on behalf of the compiler performance working group

\ Also published here

\ Photo by Antoine Gravier on Unsplash

Market Opportunity
Liberland Logo
Liberland Price(LLD)
$0.677
$0.677$0.677
-0.14%
USD
Liberland (LLD) Live Price Chart
Disclaimer: The articles reposted on this site are sourced from public platforms and are provided for informational purposes only. They do not necessarily reflect the views of MEXC. All rights remain with the original authors. If you believe any content infringes on third-party rights, please contact [email protected] for removal. MEXC makes no guarantees regarding the accuracy, completeness, or timeliness of the content and is not responsible for any actions taken based on the information provided. The content does not constitute financial, legal, or other professional advice, nor should it be considered a recommendation or endorsement by MEXC.

You May Also Like

Trading time: Tonight, the US GDP and the upcoming non-farm data will become the market focus. Institutions are bullish on BTC to $120,000 in the second quarter.

Trading time: Tonight, the US GDP and the upcoming non-farm data will become the market focus. Institutions are bullish on BTC to $120,000 in the second quarter.

Daily market key data review and trend analysis, produced by PANews.
Share
PANews2025/04/30 13:50
Ethereum Fusaka Upgrade Set for December 3 Mainnet Launch, Blob Capacity to Double

Ethereum Fusaka Upgrade Set for December 3 Mainnet Launch, Blob Capacity to Double

Ethereum developers confirmed the Fusaka upgrade will activate on mainnet on December 3, 2025, following a systematic testnet rollout beginning on October 1 on Holesky. The major hard fork will implement around 11-12 Ethereum Improvement Proposals targeting scalability, node efficiency, and data availability improvements without adding new user-facing features. According to Christine Kim, the upgrade introduces a phased blob capacity expansion through Blob Parameter Only forks occurring two weeks after Fusaka activation. Initially maintaining current blob limits of 6/9 target/max, the first BPO fork will increase capacity to 10/15 blobs one week later. A second BPO fork will further expand limits to 14/21 blobs, more than doubling total capacity within two weeks. Strategic Infrastructure Overhaul Fusaka prioritizes backend protocol improvements over user-facing features, focusing on making Ethereum faster and less resource-intensive. The upgrade includes PeerDAS implementation through EIP-7594, allowing validator nodes to verify data by sampling small pieces rather than downloading entire blobs. This reduces bandwidth and storage requirements while enhancing Layer 2 rollup scalability. The upgrade builds on recent gas limit increases from 30 million to 45 million gas, with ongoing discussions for further expansion. EIP-7935 proposes increasing limits to 150 million gas, potentially enabling significantly higher transaction throughput. These improvements complement broader scalability efforts, including EIP-9698, which suggests a 100x gas limit increase over two years to reach 2,000 transactions per second. Fusaka removes the previously planned EVM Object Format redesign to reduce complexity while maintaining focus on essential infrastructure improvements. The upgrade introduces bounded base fees for blob transactions via EIP-7918, creating more predictable transaction costs for data-heavy applications. Enhanced spam resistance and security improvements strengthen network resilience against scalability bottlenecks and attacks. Technical Implementation and Testing Timeline The Fusaka rollout follows a conservative four-phase approach across Ethereum testnets before mainnet deployment. Holesky upgrade occurs October 1, followed by Sepolia on October 14 and Hoodi on October 28. Each testnet will undergo the complete BPO fork sequence to validate the blob capacity expansion mechanism. BPO forks activate automatically based on predetermined epochs rather than requiring separate hard fork processes. On mainnet, the first BPO fork launches December 17, increasing blob capacity to 10/15 target/max. The second BPO fork activates January 7, 2026, reaching the final capacity of 14/21 blobs. This automated approach enables flexible blob scaling without requiring full network upgrades. Notably, node operators face release deadlines ranging from September 25 for Holesky to November 3 for mainnet preparation. The staggered timeline, according to the developers, allows comprehensive testing while giving infrastructure providers sufficient preparation time. Speculatively, the developers use this backward-compatible approach to ensure smooth transitions with minimal disruption to existing applications. PeerDAS implementation reduces node resource demands, potentially increasing network decentralization by lowering barriers for smaller operators. The technology enables more efficient data availability sampling, crucial for supporting growing Layer 2 rollup adoption. Overall, these improvements, combined with increased gas limits, will enable Ethereum to handle higher transaction volumes while maintaining security guarantees. Addressing Network Scalability Pressures The Fusaka upgrade addresses mounting pressure for Ethereum base layer improvements amid criticism of Layer 2 fragmentation strategies. Critics argue that reliance on rollups has created isolated chains with limited interoperability, complicating user experiences. The upgrade’s focus on infrastructure improvements aims to enhance base layer capacity while supporting continued Layer 2 growth. The recent validator queue controversy particularly highlights ongoing network scalability challenges. According to a Cryptonews report covered yesterday, currently, over 2M ETH sits in exit queues facing 43-day delays, while entry queues process in just 7 days.Ethereum Validator Queue (Source: ValidatorQueue) However, Vitalik Buterin defended these delays as essential for network security, comparing validator commitments to military service requiring “friction in quitting.” The upgrade coincides with growing institutional interest in Ethereum infrastructure, with VanEck predicting that Layer 2 networks could reach $1 trillion market capitalization within six years. Fusaka’s emphasis on data availability and node efficiency supports Ethereum’s evolution toward seamless cross-chain interoperability. The upgrade complements initiatives like the Open Intents Framework, where Coinbase Payments recently joined as a core contributor. The initiative, if successful, will address the $21B surge in cross-chain crime. These coordinated efforts aim to unify the fragmented multichain experience while maintaining Ethereum’s security and decentralization principles
Share
CryptoNews2025/09/19 16:37
VectorUSA Achieves Fortinet’s Engage Preferred Services Partner Designation

VectorUSA Achieves Fortinet’s Engage Preferred Services Partner Designation

TORRANCE, Calif., Feb. 3, 2026 /PRNewswire/ — VectorUSA, a trusted technology solutions provider, specializes in delivering integrated IT, security, and infrastructure
Share
AI Journal2026/02/05 00:02