Si el enlazado es el paso lento de tu build en Rust o C++, mold 3.0 es el reemplazo directo más rápido que existe, y se activa con tres líneas de configuración. La versión 3.0.0 de este fast linker para Linux salió el 5 de octubre y reescribe el enlazador de C++ a Rust sin cambiar nada en cómo lo usas. Acepta las mismas opciones de línea de comandos que la 2.42.1, soporta las mismas arquitecturas y genera la misma salida, salvo por las correcciones de errores.
¿Qué es un linker y por qué importa el tiempo de enlazado?
Un linker (enlazador) es el programa que une todos los archivos objeto de tu proyecto en un único ejecutable o biblioteca compartida. Compilar un lenguaje como C, C++ o Rust ocurre en dos fases. Primero, el compilador convierte cada archivo fuente en un archivo objeto (.o). Después, el linker combina todos esos objetos.
En proyectos grandes, esa segunda fase se vuelve lenta, y donde más se nota es en el ciclo de editar, recompilar y probar. Si cambias una sola línea, el compilador rehace muy poco trabajo, pero el linker a menudo tiene que rehacerlo todo.
mold es obra de Rui Ueyama, el desarrollador original de lld, el linker de LLVM con el que se construyen Android, Chrome y FreeBSD, entre otros. mold nació como su intento de crear algo más rápido desde cero, sin los límites de arquitectura que encontró al optimizar lld. Está en producción desde 2021, tiene más de 140 contribuidores y 17.5k estrellas en GitHub, y es el linker por defecto de muchos proyectos open source grandes.
¿Qué cambia en mold 3.0?
El cambio principal es el lenguaje. La 3.0 es la primera versión de mold en Rust, y la 2.42.1 es la última en C++. Si compilas mold desde el código fuente, esto es lo que cambia:
- Cargo reemplaza a CMake.
cargo build --releaselo compila y./install-mold.shlo instala. Las antiguas opciones de CMake desaparecen. - oneTBB deja de ser una dependencia. mold sigue enlazando mimalloc de forma estática por defecto, y puedes compilarlo con
--features system-allocatorpara usar el malloc del sistema. - Un archivo corrupto ya no provoca un segfault. La versión en C++ podía leer fuera de límites con un archivo objeto malformado y morir con un segmentation fault. En la 3.0 esas lecturas tienen comprobación de límites, así que mold se detiene con un panic justo en el acceso defectuoso.
Si solo usas mold, no cambia nada. El rendimiento de enlazado está a la par de la 2.42.1: la reescritura aporta seguridad y facilidad de mantenimiento, no velocidad. Para verificar la compatibilidad, los mantenedores ejecutaron la suite de tests en todas las arquitecturas soportadas, compararon la salida en cargas de trabajo reales y compilaron todos los paquetes de Gentoo. Reportan cero regresiones. La versión incluye además una larga lista de correcciones, sobre todo en la salida reubicable (-r) y en arquitecturas menos comunes.
La ambición grande está por delante. El objetivo declarado de la serie 3.x es cerrar las brechas de compatibilidad que quedan con GNU ld, en especial el soporte de linker scripts. Eso convertiría a mold en una opción práctica como /usr/bin/ld por defecto de una distribución Linux, y abriría la puerta a enlazar kernels y firmware embebido. Al momento de publicar esta nota, eso es una hoja de ruta, no una función de la 3.0.
¿Se reescribió mold en Rust con ayuda de IA?
Sí, en parte, y está documentado en el propio repositorio. Al momento de publicar esta nota, decenas de commits del historial de mold llevan la firma Co-Authored-By: Claude. Los de Ueyama citan a Claude Fable 5, y los del contribuidor Chris Allen, a Claude Opus 5.5.
No son commits cosméticos. Uno de agosto, por ejemplo, paraleliza el ordenamiento de los 44.683 archivos de entrada de un enlace de Chromium, un paso que antes tomaba 7 ms en un solo hilo. Otros corrigen un bucle infinito en archivos thin archive o un puntero colgante en el plugin de LTO.
Es uno de los casos más visibles hasta ahora de un mantenedor experto que usa un agente de código para portar una herramienta de sistemas crítica. Y lo publica con un nivel de verificación que pocos proyectos igualan: el árbol completo de Gentoo compilado con mold, con GNU ld como control, antes de cada versión.
¿mold o lld: cuál es más rápido?
mold es más rápido que lld por un margen amplio, según los benchmarks del propio proyecto. Son cifras autorreportadas, publicadas en el README de mold y medidas en agosto de 2026 en dos máquinas. Los tres linkers comparados se compilaron desde el código fuente y se ejecutaron con sus opciones por defecto. En la mediana, el README reporta mold como 4,9× más rápido que lld y 1,9× más rápido que wild.
Algunos enlaces representativos de builds de depuración en un AMD Threadripper 7980X de 64 núcleos:
| Programa | lld | mold |
|---|---|---|
| Chromium 145 | 16,64 s | 1,65 s |
| Clang 21 | 6,19 s | 1,34 s |
| Godot 4.6 | 1,77 s | 0,46 s |
| TensorFlow 2.21 | 50,73 s | 3,15 s |
Dos matices mantienen la comparación mold vs lld honesta:
- La diferencia se reduce con menos núcleos. En un Apple M1 Ultra limitado a sus 16 núcleos de rendimiento, el enlace de depuración de Clang 21 pasa de 4,40 s con lld a 2,96 s con mold. Eso es 1,5×, no 4,6×. La velocidad de mold viene del paralelismo, así que cuantos más núcleos, más gana.
- wild a veces empata o gana. wild es otro fast linker escrito en Rust, solo para Linux. En el M1 Ultra le gana a mold en algunos builds de release; Blender, por ejemplo, tarda 0,20 s con wild contra 0,25 s con mold. Eso sí, wild no logra enlazar varios de los programas del benchmark.
La tabla compara mold con lld y wild, no con GNU ld, que es el linker por defecto en la mayoría de los sistemas Linux. Si nunca has cambiado de linker, tu punto de partida es GNU ld, y esa es la comparación que te conviene medir en tu propio proyecto.
¿Cómo usar mold con Rust y Cargo?
Crea el archivo .cargo/config.toml en el directorio de tu proyecto:
[target.'cfg(target_os = "linux")']
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/path/to/mold"]
Reemplaza /path/to/mold por la ruta absoluta al ejecutable de mold. El ejemplo usa clang como linker driver porque siempre acepta -fuse-ld. Si tu GCC es lo bastante reciente para reconocer esa opción, puedes quitar la línea linker y usar la forma corta:
[target.'cfg(target_os = "linux")']
rustflags = ["-C", "link-arg=-fuse-ld=mold"]
Para usar mold en todos tus proyectos de Rust, pon el mismo bloque en ~/.cargo/config.toml.
¿Cómo usar mold con C o C++ en GCC y Clang?
Basta con añadir una opción a tu compiler driver:
- Clang:
-fuse-ld=mold - GCC 12.1.0 o posterior:
-fuse-ld=mold - GCC anterior a 12.1.0: las versiones viejas no aceptan
moldcomo valor de-fuse-ld, así que usa-B. Si instalaste mold con su script, pasa-B/usr/local/libexec/moldy ajusta el prefijo si lo instalaste en otro lugar.
Si no puedes tocar las opciones del sistema de build, mold puede interceptar el linker por ti:
mold -run make <opciones-de-make>
Esto redirige a mold cualquier llamada a ld, ld.bfd, ld.gold o ld.lld. Funciona en Linux y FreeBSD. Para CI, el proyecto mantiene una GitHub Action llamada setup-mold.
¿Cómo instalar mold?
La forma más sencilla es el gestor de paquetes de tu distribución, porque mold está ampliamente empaquetado. Revisa en Repology qué versión ofrece tu distribución, ya que la 3.0 tardará en llegar a todos los repositorios. Cada release de GitHub incluye también binarios precompilados para Linux en x86-64, ARM64, ARM32, RISC-V, PPC64LE, s390x y LoongArch.
Para compilarlo desde el código fuente necesitas un toolchain estable y reciente de Rust y un compilador de C. Las notas de la versión indican la versión mínima exacta.
git clone https://github.com/rui314/mold.git
cd mold
cargo build --release
sudo ./install-mold.sh
El script instala mold en /usr/local. Define PREFIX para instalarlo en otro lugar, por ejemplo sudo PREFIX=/usr ./install-mold.sh.
¿Cómo comprobar que mold enlazó tu binario?
mold deja una cadena de identificación en la sección .comment del archivo de salida:
readelf -p .comment <archivo-ejecutable>
Si la salida incluye una línea que empieza por mold, ese binario lo enlazó mold. Ejecuta esta comprobación una vez después de cambiar la configuración: una opción que no se aplicó en silencio se ve exactamente igual que un linker que no es más rápido.
¿Funciona mold en macOS o Windows?
No. Al momento de publicar esta nota, el README documenta Linux, con mold -run disponible también en FreeBSD. Sus binarios precompilados son solo para Linux, y no hay una ruta documentada para macOS ni Windows. En esas plataformas, mold no es una opción hoy.
¿Qué se rompe con la reescritura en Rust?
Para la mayoría de los desarrolladores, nada, porque la 3.0 es un reemplazo directo (drop-in replacement). El costo recae en un grupo pequeño: las distribuciones Linux que compilan todo su toolchain desde el código fuente y usaban mold como linker en las primeras etapas.
El problema es de orden. Cuando una distribución construye todo desde cero, el toolchain de C y C++ va primero y Rust llega mucho después. Un linker en C++ se podía compilar temprano y usar para enlazar todo lo demás, incluido el propio Rust. Un linker en Rust no se puede compilar hasta que Rust exista.
En la discusión de la versión en Hacker News, el co-mantenedor de una distribución que usa mold como linker del sistema explicó el efecto. Su distribución tendrá que seguir manteniendo la versión en C++, a la que llamó “mold2”, para la etapa de bootstrap, y solo podrá pasar a mold 3 para el software que se compila después de Rust.
Eso importa en el bootstrapping desde el código fuente y en los builds endurecidos contra ataques a la cadena de suministro. No afecta a quien instala mold desde un paquete o un binario de release.
¿Y tú? ¿Cuánto tarda hoy el enlazado en tu build más pesado, y lo has medido alguna vez?
- El que viene por defecto (GNU ld)
- lld
- mold
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: Zig 0.17: qué se rompe en tu build.zig y cómo activar la compilación incremental