Mold 3.0 lança sua reescrita em Rust como linker de substituição direta

O Mold 3.0, a primeira versão escrita em Rust desse linker rápido para Linux, foi lançado em 5 de outubro de 2026. Seu autor, Rui Ueyama, reescreveu o programa inteiro a partir do C++. As notas de lançamento prometem uma troca limpa: as mesmas opções, a mesma saída e a mesma velocidade do mold 2.42.1, a última versão em C++. Isso importa porque o mold agora quer se tornar o linker padrão do Linux.

O que um linker faz e onde o mold se encaixa

Um linker é a última etapa da compilação de um programa. O compilador transforma cada arquivo-fonte em um arquivo-objeto. Depois, o linker junta essas peças em um único programa que pode ser executado. Em projetos grandes, essa etapa pode levar muitos segundos, e ela roda de novo após cada pequena alteração.

A maioria dos sistemas Linux usa por padrão o GNU ld, o linker do projeto GNU. O lld do LLVM é uma alternativa mais rápida. O mold foi criado para superar os dois. Seu repositório lista estes tempos de ligação, de testes feitos em agosto de 2026:

Programa	mold	LLVM lld	Aceleração
Chromium 145	1,65 s	16,64 s	10,1x
TensorFlow 2.21	3,15 s	50,73 s	16,1x
ClickHouse 26.1	0,98 s	6,62 s	6,7x

Esses números foram medidos na versão em C++. As notas de lançamento do 3.0 dizem que a velocidade de ligação "continua no mesmo nível do 2.42.1", então a versão em Rust reivindica os mesmos resultados. Ueyama apresentou o plano pela primeira vez em setembro: Reescrita do mold em Rust quer ser o linker padrão do Linux.

O que mudou no mold 3.0

Para quem apenas chama o mold, nada deve parecer diferente. Segundo as notas de lançamento no GitHub e o Phoronix, o mold 3.0:

• aceita as mesmas opções de linha de comando do 2.42.1
• suporta as mesmas arquiteturas de CPU, incluindo x86-64, AArch64, RISC-V e LoongArch
• produz a mesma saída, exceto onde bugs foram corrigidos
• faz a ligação na mesma velocidade do 2.42.1

As mudanças reais estão na forma como o próprio mold é compilado. Agora ele usa o Cargo, a ferramenta de build padrão do Rust, em vez do CMake. Compilá-lo exige Rust 1.95 ou posterior.

Ele também abandona o oneTBB, uma biblioteca da Intel que divide o trabalho entre os núcleos do processador. Era mais um pacote que as distribuições Linux tinham de entregar junto com o mold.

Por que reescrever em Rust um linker que funciona

O principal motivo é a segurança. Um linker lê arquivos-objeto que ele não criou. Depois, faz uma grande quantidade de trabalho de memória de baixo nível sobre eles.

Em C++, um único arquivo de entrada defeituoso pode fazer esse código ler memória que nunca deveria tocar. A Hardware Busters informou em setembro que é exatamente aí que um bug de memória vira um bug de segurança. O Rust verifica essas leituras automaticamente. Segundo o Phoronix, o resultado é que o mold agora está mais seguro ao lidar com arquivos de entrada corrompidos.

O que vem a seguir: scripts de ligação e o posto de padrão

A série 3.x tem um alvo claro. A meta declarada do projeto é "fechar as lacunas de compatibilidade que restam com o GNU ld, principalmente no suporte a scripts de ligação". Ele também quer "abrir caminho para que o mold seja adotado como linker padrão nas distribuições Linux".

Scripts de ligação são pequenos arquivos que dizem a um linker exatamente onde colocar o código na memória. Kernels de sistemas operacionais, bootloaders e firmware de dispositivos pequenos dependem deles. O mold não conseguia fazer a ligação desses programas antes, segundo a Hardware Busters. Até que consiga, as distribuições não podem torná-lo o padrão do sistema.

O que isso significa para os desenvolvedores

Trate o 3.0 como uma substituição direta e depois verifique. Se você já usa o mold, suas flags de build não devem precisar mudar. Primeiro, faça a ligação de um projeto real com o 2.42.1 e com o 3.0. Depois, rode toda a sua suíte de testes antes de trocar suas máquinas de CI.

Confira seu compilador se você compila o mold por conta própria. É preciso ter Rust 1.95 ou posterior, então o Rust mais antigo empacotado por algumas distribuições de suporte de longo prazo pode não conseguir compilá-lo. Os empacotadores perdem a dependência do oneTBB, mas assumem um build com Cargo.

Meça seus próprios tempos de ligação. As acelerações da tabela vêm do próprio repositório do mold, e foram medidas antes da reescrita. Cronometre um build completo e uma pequena recompilação incremental no seu próprio código, antes e depois da troca.

Acompanhe as distribuições. Se uma grande distribuição tornar o mold seu linker padrão, todo build naquele sistema vai usá-lo sem que ninguém peça. Essa decisão agora depende do suporte a scripts de ligação na série 3.x. Os desenvolvedores de kernel e de sistemas embarcados são o grupo a observar primeiro.