Índice de contenidos
Claves de la noticia
- mold 3.0 es la primera versión del enlazador reescrita de C++ a Rust, publicada este 5 de octubre.
- El proyecto promete conservar opciones, arquitecturas y rendimiento, mientras cambia el sistema con el que se construye.
- Los paquetes preparados desde el código necesitan revisar Cargo, la instalación y las bibliotecas; adoptar Rust no acredita otra aceleración.
El enlazador mold acaba de completar una transición importante para quienes construyen software en Linux. Rui Ueyama ha publicado la versión 3.0.0, con una implementación en Rust y una promesa de continuidad para sus usuarios. La comparación de sus documentos revela una diferencia práctica: utilizar el programa y fabricar el paquete que lo contiene exigen revisiones distintas.
Veinticuatro días entre dos versiones
Las notas oficiales de mold 3.0.0 sitúan esta entrega como sustituta directa de 2.42.1. Su autor mantiene el objetivo de acercarlo al puesto de enlazador predeterminado de las distribuciones Linux. La publicación es verificable en GitHub y está firmada por el mismo mantenedor que administra el repositorio.
El antecedente fechado importa. La versión 2.42.1 del 11 de septiembre ya explicaba la reescritura y la intención de ampliar la compatibilidad. Al comparar las fechas de ambas entregas, transcurren 24 días naturales entre la última versión en C++ y la primera en Rust. Ese intervalo mide publicaciones, no la duración del trabajo: no permite afirmar que toda la conversión se hizo en tres semanas.
También evita confundir un programa disponible con una hoja de ruta culminada. El objetivo anunciado en septiembre incluía cerrar lagunas de los scripts de enlazado y trabajar con los responsables de distribuciones. La llegada de 3.0 no demuestra por sí sola que estas hayan sustituido GNU ld ni que cualquier núcleo o firmware sea ya compatible.
El ejecutable cambia menos que su fábrica
Un enlazador reúne los archivos objeto producidos por un compilador para obtener un ejecutable o una biblioteca. Por eso mold puede intervenir al construir proyectos de C, C++ o Rust: el lenguaje en el que se programa la herramienta no obliga a convertir los proyectos que procesa.
El archivo Cargo.toml de esta versión permite comprobar decisiones concretas: identifica el paquete como un enlazador ELF, declara Rust 1.95 y la edición 2024, y organiza el espacio de trabajo con componentes para la interfaz de comandos, las arquitecturas y las pruebas. No son especificaciones inferidas de una etiqueta comercial; están en la configuración utilizada para construirlo.
La lectura conjunta de esa configuración y las instrucciones de instalación delimita quién necesita actuar. Un desarrollador que recibe un binario de su distribución revisa su integración con el proyecto. Un mantenedor que lo fabrica debe revisar además el compilador disponible y la receta del paquete. La compatibilidad de uso no implica compatibilidad de la receta de construcción.
| Capa | Comprobación práctica |
|---|---|
| Uso en un proyecto | Opciones de enlazado y pruebas del ejecutable |
| Construcción del paquete | Cargo y versión mínima de Rust |
| Instalación | Prefijo, bibliotecas y destino del paquete |
La tabla separa responsabilidades que suelen mezclarse al hablar de una reescritura. Actualizar el compilador del entorno que fabrica mold no equivale a cambiar el compilador de todas las aplicaciones. Mantener esa distinción reduce cambios innecesarios en equipos de desarrollo y en integración continua.
Una instalación que se puede auditar
El script de instalación incluido en la etiqueta comprueba que existen el ejecutable y mold-wrapper.so antes de copiar archivos. Establece /usr/local como prefijo predeterminado, admite un destino de empaquetado y distribuye binario, biblioteca, manual y licencia en directorios separados.
Su contenido permite detectar una consecuencia específica para quienes empaquetan: la biblioteca auxiliar no desaparece aunque cambie el sistema de construcción. Las rutas de instalación siguen formando parte de la integración. Una receta que solo copie el ejecutable puede omitir un componente que el script considera necesario; una que prepare un paquete para otra raíz necesita conservar correctamente el destino.
Esta es una comprobación documental, no una prueba ejecutada en nuestro servidor. No se ha construido mold ni se ha medido su comportamiento. La información publicada permite preparar una revisión de la receta, pero el resultado de esa revisión depende del entorno que emplee cada equipo.
Medir el enlace sin atribuirle toda la compilación
El README de la versión 3.0.0 conserva pruebas de rendimiento fechadas en agosto. Explica el hardware, las condiciones y que se toma la mediana de tres ejecuciones tras un calentamiento. Esa fecha impide tratar la tabla como una nueva medición comparativa entre la entrega en Rust y su predecesora.
Las notas de la nueva versión afirman que el rendimiento de enlazado se mantiene a la altura de 2.42.1. Es una declaración del proyecto; no la presentamos como benchmark independiente. Para evaluar una actualización conviene separar el tiempo de enlace del tiempo total de construcción. Una mejora en una fase no se traslada íntegra al proceso completo.
Esta distinción conecta con las mediciones recientes del compilador de Rust y con el trabajo de Headstart sobre compilaciones incrementales: intervienen en mecanismos diferentes. Sumar porcentajes de esas noticias al rendimiento de mold produciría una mejora ficticia.
La decisión útil para un equipo es identificar primero qué fase consume su espera. Si domina el enlace, mold merece una evaluación con sus archivos y opciones. Si dominan la compilación o las tareas previas, sustituir el enlazador puede aportar menos. La novedad de hoy permite avanzar hacia una herramienta mantenida en Rust, pero exige comprobar por separado la integración, el paquete y el ahorro efectivo de tiempo.
