See also en PoC in #36120.

LLD puede ser un muy buen candidato para los objetivos de MinGW, porque actualmente incluimos un enlazador con ellos de todos modos y el enlazador de MinGW tiene una variedad de problemas que van desde la falta de ASLR hasta la falta de compatibilidad con bigobj. Si de alguna manera también podemos traer las bibliotecas mingw necesarias al realizar la compilación cruzada y no solo la orientación nativa (a la que el paquete mingw de rustup está actualmente limitado), entonces eso permitiría la compilación cruzada de rust desde linux, lo que sería una gran mejora sobre la situación existente en la que las personas obtienen MinGW de su distribución y luego se encuentran con problemas porque las distribuciones casi siempre usan un MinGW incompatible.

LLD no es un buen candidato para apuntar de forma nativa a objetivos de MSVC, debido a varias razones, la razón principal es la falta de soporte de debuginfo. La compilación cruzada para objetivos de MSVC requiere bibliotecas que no se pueden redistribuir, por lo que no podemos admitirlo de forma inmediata.

El problema de seguimiento para actualizar a LLVM 4.0 es https://github.com/rust-lang/rust/issues/37609 .

Para el registro, lld definitivamente no está listo para los objetivos de Solaris. Pero en Solaris, no hay ninguna razón que sepa para usar lld en lugar del ld nativo. Ya hemos estado analizando lo que se necesitaría para que rust usara Solaris ld en Solaris en lugar de usar gcc para la vinculación.

@binarycrusader Una razón para usar lld es cuando se crea para Solaris, no en Solaris.

PR rust-lang / rust # 40018 agrega un indicador -Z linker-flavor a rustc para hacer posible el uso de LLD como enlazador. Ese PR no incrusta LLD en rustc pero permite la experimentación fuera del árbol con él.

@binarycrusader ^ que puede ayudar con su experimento de usar directamente el ld de Solaris en lugar de gcc.

Ahora parece que nos estamos ejecutando en LLVM 4.0. @japaric , ¿esto significa que la bandera de sabor del enlazador ahora se puede usar fácilmente para comparar y contrastar LLD con el enlazador del sistema?

@bstrie # 40018 aterrizó hace unas semanas. Desde que aterrizó, uno ha podido usar -Z linker-flavor=ld -C linker=ld.lld para usar un binario LLD externo como enlazador. Tenga en cuenta que, a diferencia de gcc, LLD no sabe dónde están las bibliotecas del sistema, por lo que tendrá que pasar la ruta de búsqueda de la biblioteca al vinculador usando -C link-args='-L ...' si está vinculando a cualquier biblioteca del sistema.

Con lo que ayuda LLVM 4.0 es fusionar LLD en rustc. Con ese cambio, no necesitaríamos un enlazador externo en algunos escenarios como enlazar binarios MUSL o programas bare metal. Digo algunos escenarios porque la mayoría de los objetivos requieren vincularse a las bibliotecas del sistema donde se encontrará con el problema de la ruta de búsqueda de la biblioteca que mencioné anteriormente. Para esos objetivos, LLD no funcionará de inmediato. No está claro cómo y dónde resolver ese problema y sin una solución para eso no podemos cambiar a LLD para los objetivos más importantes (nivel 1), lo que reduce el atractivo de incrustar LLD en rustc en primer lugar.

@japaric ¿Cuáles son los argumentos en contra de incrustar rutas de búsqueda (biblioteca relativa a sysroot), así como cosas como -lc -lpthread crt0.o , directamente en rustc? Después de todo, algún componente de la cadena de herramientas tiene que incrustarlos, ya que no tenemos ningún estándar a seguir para las plataformas, y binutils no es una buena fuente de oro para este conocimiento.

El único inconveniente en el que puedo pensar es la situación en la que el mismo triple tendría diferentes rutas de búsqueda en diferentes tipos de sistemas (que probablemente serán exclusivos de los triples de Linux / glibc, y especialmente malo en plataformas con multilib). En ese caso, creo que clang fisgonea el nombre del sistema operativo y codifica las convenciones específicas del sistema operativo, lo que parece malo pero probablemente inevitable si uno quiere distribuir un solo binario que se ejecuta en cualquier Linux (y no necesita el enlazador del sistema).

@ retep998 Eché un vistazo breve a lld hace unos meses. No pude realizar una compilación cruzada (¿enlace cruzado?) Un .exe desde Linux. Parecía que lld solo admite formatos nativos de la plataforma.

Ojalá me equivoque.

Etiquetar esto como un error de rendimiento, ya que según los puntos de referencia de LLD parece superar a GNU ld por un factor de diez, y el rendimiento de vinculación es un componente importante de la velocidad del compilador en la actualidad.

Er, olvidé vincular los puntos de referencia: https://lld.llvm.org/#performance

(Relevante hoy desde que LLVM 5.0 acaba de ser lanzado).

La vinculación con LLD es mucho más rápida que bfd u gold, pero dudo que su uso mejore significativamente el rendimiento general. Aún así, creo que este tema es importante y debería ser una prioridad.

@tpimh En realidad, no estoy del todo seguro de si se supone que la etiqueta I-slow representa errores de rendimiento en tiempo de ejecución o errores de rendimiento en tiempo de compilación, tenía la intención de que fuera lo último. Y el IME cuando miro el enlace de salida de paso de tiempo generalmente se encuentra en las tres fases más largas, significativamente más largas que la mayoría, por lo que incluso reducir el tiempo de enlace a la mitad probablemente sería una gran ganancia (especialmente para cosas grandes como Servo y rustc).

@bstrie I-slow es para un mal rendimiento en tiempo de ejecución, I-compiletime es para el rendimiento del compilador la última vez que verifiqué

Buenas noticias para cualquier persona interesada en el oscuro tema de los enlaces cruzados de Linux a Windows. Dije anteriormente que no era posible con lld, pero eso solo es cierto para el sabor ld de lld. Es posible para el tipo link.exe de lld (lld-link).

Específicamente para Rust, podemos hacer esto hoy con un par de cambios en el código.

1. Necesitamos compilar un subconjunto muy pequeño de CRT de mingw-w64 en archivos de objeto .o. Es decir, algunos inicios de almacenamiento local de subprocesos. También necesitamos chkstk.

2. A lld no le gustan las bibliotecas de importación habituales de MinGW. En su lugar, necesitamos construir los archivos .def en archivos .lib nosotros mismos, usando lld-link o llvm-dlltool

3. Modifique lld para tratar a IMPORT_NAME_NOPREFIX como
   IMPORT_NAME_UNDECORATE, porque incluso con el paso 2 los .libs no son perfectos

4. Modifique seh.rs de Rust para reemplazar TYPE_INFO_VTABLE con ptr :: null (). Obligatorio porque el símbolo ??_7type_info@@6B@ no está definido en MinGW. Luego construya e instale Rust.

5. Utilice .cargo / config para especificar un script de contenedor personalizado como vinculador.

6. Nuestro script de enlazador contenedor debería invocar lld-link principalmente utilizando los parámetros que se le pasan. Sin embargo, debemos hacer algunos ajustes:

   a) Arregle la carcasa del nombre de archivo, por ejemplo, cambie AdvAPI32.Lib a advapi32.lib

   b) Modifique el archivo .def que genera Rust para prefijar símbolos con un guión bajo adicional

   c) Anule el punto de entrada (/ entrada). Obligatorio probablemente debido a un problema de alteración de nombres.

   d) Adjunte los archivos de objeto mingw-crt que compiló en el paso 1

7. Construya su proyecto de Rust usando xargo --target = i686-pc-windows-msvc

Hacer los pasos anteriores me permite compilar el código de Rust de forma cruzada. Incluso puedo entrar en pánico y atraparme en pánico usando el desenrollado basado en SEH de Rust.

@iainnicol Estás mezclando el objetivo msvc con bits MinGW, por lo que tienes que hacer todas esas modificaciones extrañas. Si simplemente copia las bibliotecas de una instalación de VC ++ existente, entonces puede usar lld-link normalmente sin todas esas modificaciones o bits MinGW.

Pero no quiero usar una instalación de VC ++ existente. Ni siquiera hay forma de conseguir uno sin pasar unas ocho horas descargando e instalando basura, y mucho menos para redistribuir.

Las herramientas de compilación independientes son mucho más livianas, a menos que ya se esté refiriendo a eso, en cuyo caso quizás deberíamos trabajar un poco para mejorar o recrear lo que hizo MinGW para que sea realmente compatible con MSVC.

Las herramientas de construcción independientes son mucho más ligeras

No me he dado cuenta de que Microsoft los distribuye. ¿Podrías vincularlos? ¿Hay alguna forma razonable de extraer el archivo de instalación sin ejecutarlo, es decir, es un msi o algo similar?

Aquí están: http://landinghub.visualstudio.com/visual-cpp-build-tools

Tanto la versión 2015 como la 2017 son exes, pero es posible que pueda convencer al exe 2017 para que le dé lo que desea a través de esto: https://docs.microsoft.com/en-us/visualstudio/install/install-vs- red de calidad inconsistente

Si realmente queremos hacer esto correctamente para Windows, primero necesitaríamos https://github.com/rust-lang/rust/issues/30027 para eliminar la necesidad del SDK de Windows o las bibliotecas de importación de MinGW. Entonces, todo lo que nos quedaría es reemplazar los bits CRT con nuestras propias versiones Rust puras (funciones matemáticas / de memoria, punto de entrada, algunos otros bits de tiempo de ejecución que Rust necesita) y tendríamos una cadena de herramientas Rust completamente autónoma que puede ¡crea binarios de Windows! La desventaja de esto es que no podría vincular estáticamente el código C / C ++ porque eso depende en gran medida de la vinculación en el CRT apropiado desde MinGW o VC ++. Por supuesto, el objetivo de Rust es reescribir todo en Rust, por lo que esto no es un gran problema.

Buenas noticias para cualquier persona interesada en el oscuro tema de los enlaces cruzados de Linux a Windows. Dije anteriormente que no era posible con lld, pero eso solo es cierto para el sabor ld de lld. Es posible para el tipo link.exe de lld (lld-link).

Parece que ahora también debería ser posible con el sabor ld: https://reviews.llvm.org/rL312926

El controlador compatible con MinGW del nuevo lld es un contenedor del enlazador lld-link. Traduce internamente las opciones de Unix-ish a opciones de Windows-ish y luego llama al punto de entrada de lld-link. No estoy seguro de si quieren usarlo porque (excepto que el controlador de envoltura está incompleto y no está listo para usar) no parece facilitar las cosas a menos que ya tenga Makefiles para MinGW.

Tengo una pregunta (probablemente tonta) para ustedes acerca de la compilación cruzada. En Windows, todos los símbolos dllimportados tienen nombres DLL desde los que se importan. Si no tiene ningún archivo de biblioteca MSVC, ¿cómo sabe de qué archivos se importan los símbolos dllimportados?

Tengo una pregunta (probablemente tonta) para ustedes acerca de la compilación cruzada. En Windows, todos los símbolos dllimportados tienen nombres DLL desde los que se importan. Si no tiene ningún archivo de biblioteca MSVC, ¿cómo sabe de qué archivos se importan los símbolos dllimportados?

Si no tiene ninguna biblioteca de importación, entonces debe crear bibliotecas de importación o implementar https://github.com/rust-lang/rust/issues/30027 para que winapi pueda hacer todo lo difícil trabajo de especificar de qué DLL proviene cada símbolo junto con locura como ordinales. Algo tiene que especificar el mapeo de símbolos en el momento del enlace a símbolos / ordinales en archivos DLL, ya sean bibliotecas de importación o anotaciones en su código.

Después de ingresar https://reviews.llvm.org/rL311734 , casi puedo arrancar rustc usando lld en macOS. Parece haber un problema con los metadatos de dylib, que aún necesito investigar.

Tengo una rama que resucita https://github.com/rust-lang/rust/pull/36120; ya que necesitamos esa solución lld (muy reciente), esto está bloqueado en https://github.com/rust-lang/rust/issues/43370.

@tamird : # 43370 ha sido cerrado.

LLD se ha agregado en https://github.com/rust-lang/rust/pull/48125 y ahora se envía con plataformas de nivel 1 (mac, linux, windows). Puede probarlo con -Z linker-flavor para cada plataforma, aunque es poco probable que funcione para la mayoría de las plataformas de forma predeterminada. Sin embargo, funciona de forma predeterminada en MSVC. Por ejemplo:

$ RUSTFLAGS='-Z linker-flavor=lld-link' cargo build

redujo el tiempo de enlace de Cargo de 2,5 sa 1,5 s, ¡una buena mejora!

@alexcrichton , ¿cuáles son los próximos pasos? Idealmente, tendríamos LLD funcionando de forma predeterminada en todas las plataformas (no tengo idea de cuánto trabajo llevará esto), y luego me gustaría ejecutar puntos de referencia en tiempo de compilación / tiempo de ejecución para ver si tiene sentido hacer que LLD sea el predeterminado en cualquier plataforma. Especialmente con la compilación incremental, el rendimiento de la vinculación será más importante que nunca.

Especialmente con la compilación incremental, el rendimiento de la vinculación será más importante que nunca.

Es una pena que el rendimiento de los enlaces aún no sea lo suficientemente importante para que podamos hacer cosas como habilitar el enlace incremental en las plataformas que lo admiten. https://github.com/rust-lang/rust/issues/37543

@bstrie Supongo que esos son los próximos pasos, hacer que funcione en otras plataformas :)

En cuanto a lo que eso implica, no estoy seguro, pero ya funciona en MSVC, creo que está lejos de funcionar en MinGW / Linux, y estamos bastante cerca de OSX. En cuanto al soporte de arquitectura cruzada, tampoco estoy seguro. No espero que lo "estabilicemos" para otra cosa que no sea la plataforma wasm en un futuro próximo.

@alexcrichton ¿ Puedo preguntar cómo especificaría "estabilizar"? ¿Por qué no sería posible "estabilizar" el enlace con lld para las otras plataformas principales que rust soporta? (por ejemplo, compilación cruzada de un ejecutable desde linux para macOS).

En este momento, la compilación cruzada es una molestia, por ejemplo, el trabajo necesario para compilar un ejecutable para macOS (x86_64-apple-darwin) desde linux requiere pasos no triviales como adquirir el xcode sdk y construir toda la cadena de herramientas.

@cynecx ¡ una buena pregunta! Uno en el que no he pensado mucho. Sin embargo, creo que no queremos estabilizar de facto LLD solo porque lo agregamos para otra plataforma, requerirá tiempo y trabajo para hacerlo bien y exponerlo bien.

por ejemplo, el trabajo necesario para realizar una compilación cruzada de un ejecutable para macOS (x86_64-apple-darwin) desde linux requiere pasos no triviales como adquirir el xcode sdk y construir toda la cadena de herramientas.

LLD realmente no ayudaría aquí, aún necesita el SDK de Xcode porque tiene encabezados que no puede redistribuir (y dependiendo de lo que esté creando, también necesitará otras herramientas de SDK).

Lo que es realmente bueno acerca de LLD ahora integrado en todas las noches es que puede compilar fácilmente proyectos Rust puros de Windows a Linux con RUSTFLAGS='-Z linker-flavor=ld.lld' cargo build --target x86_64-unknown-linux-musl . Excelente para escribir pequeñas herramientas para máquinas Linux en las que no puede simplemente instalar Rust.

No espero que lo "estabilicemos" para otra cosa que no sea la plataforma wasm en un futuro próximo.

Como dijo @rkarp , un caso de uso muy común apunta a x86_64-unknown-linux-musl (y eventualmente steed) para soportar cargas de trabajo de Linux en contenedores. Esta es una de esas cosas que Go hace realmente bien y en la que parecemos estar muy cerca de que Rust pueda hacer lo mismo. En términos de uso real, apuesto a que LLD para x86_64-unknown-linux-musl en realidad se usaría mucho más ampliamente que wasm.

De manera más general, cuando se trata de construcción cruzada, no creo que tenga sentido un enfoque de "debe funcionar para todos los hosts y / o todos los objetivos". Creo que tiene sentido estabilizar esto objetivo por objetivo a medida que los objetivos comienzan a funcionar.

En particular, me encantaría ayudar con el esfuerzo de conseguir que LLD para el objetivo x86_64-unknown-linux-musl se estabilice lo antes posible.

Mi proyecto tiene 37 cajas y los enlaces de compilación alrededor de 70 binarios (muchas pruebas). De manera no científica (mirando top ) al menos la mitad del tiempo de compilación, solo estamos ejecutando ld. Espero que el uso de lld acelere mucho nuestras compilaciones. Estamos en Rust estable y aún no he logrado que lld 6.0 funcione.

@briansmith, ¿ ha probado LLD para musl y su caso de uso? En teoría, todo lo que tendría que hacer para probarlo es pasar -Z linker-flavor=ld.lld , y si eso funciona parece plausible, ¡podríamos cambiar los valores predeterminados!

@rocallahan solo para confirmar, todos ustedes están usando el enlazador dorado actualmente, ¿verdad? (como afaik es más rápido que el enlazador binutils estándar). Si -Z linker-flavor=ld.lld funciona (y es más rápido), ¡quizás podríamos intentar estabilizarlo! ¿En qué plataforma estaba eso?

De forma no científica (ojo superior) al menos la mitad del tiempo de compilación solo estamos ejecutando ld.

Eso es para una compilación de depuración BTW.

Ustedes están usando el enlazador dorado actualmente, ¿verdad? (como afaik es más rápido que el enlazador binutils estándar)

No, ese es el enlazador del sistema Fedora, el enlazador GNU estándar.

¿En qué plataforma estaba eso?

Fedora 27, portátil Skylake de cuatro núcleos con SSD. Obtendré algunos números de rendimiento.

¡Ah, bueno, bueno saberlo! Las compilaciones de depuración probablemente obtendrán el mayor beneficio en el tiempo de enlace de split Dwarf (https://github.com/rust-lang/rust/issues/34651) en lugar de las mejoras del enlazador.

Sin embargo, para obtener información sobre el tiempo, @rocallahan , si tiene la oportunidad de realizar una prueba mental con ld.gold y ld.lld ?

Seguro. También debo recordar que el problema # 48762 es muy fácil para acelerar los tiempos de enlace de depuración de Linux. (Ya estamos usando un script de enlazador pirateado que elimina .debug_pubnames / .debug_pubtypes del ejecutable).

Split DWARF puede ser bueno, pero también puede causar problemas a los usuarios. Comentaré en ese tema.

@briansmith, ¿ ha probado LLD para musl y su caso de uso? En teoría, todo lo que necesita hacer para probarlo es pasar -Z linker-flavour = ld.lld, y si eso funciona parece plausible, ¡podríamos cambiar los valores predeterminados!

Bien, probaré cosas. Quizás inicialmente debería haber un término medio entre "predeterminado" y "solo por la noche", alguna forma de optar por usar LLD como podemos con -Z , pero sin usar -Z para que funcione en construcciones estables.

pero sin usar -Z para que funcione en compilaciones estables.

Puedes probar RUSTC_BOOTSTRAP=1 RUSTFLAGS="-Z linker-flavor=foo" cargo build

Por favor, ¿no recomendamos la bandera de arranque? Me preocupa que si suficientes proyectos dependen de él, las cosas se volverán estables de facto, derrotando el punto de todo el mecanismo de estabilidad.

Lo siento = /

Como punto de datos, la vinculación de la caja rustc_trans en el repositorio de Rust se desplomó de un tiempo de enlace de 78 segundos a un tiempo de enlace de 1 segundo en mi máquina local.

Mi desempeño es el resultado de hacer un cambio de espacio en blanco a una caja cerca de la parte inferior de nuestra jerarquía de cajas. Laptop Skylake de cuatro núcleos, 16GB RAM, rustc 1.24.0, LLD 7.0.0, GNU ld 2.29-13. Usamos un script de enlazador personalizado que descarta .debug_pubnames y .debug_pubtypes ; LLD usa rutas de código bastante diferentes cuando hay un script de enlace, por lo que eso podría afectar las cosas.

GNU ld:

real    2m39.138s
user    8m18.992s
sys 1m37.513s

LLD:

real    2m19.164s
user    6m4.477s
sys 0m56.858s

El oro no funcionó, vomitó en nuestro script de enlace. Los resultados son bastante estables. LLD no afecta mucho el tiempo de un extremo a otro, pero reduce significativamente el uso de la CPU; Supongo que eso significa que nuestra compilación no pasa mucho tiempo esperando que los lds terminen, pero gasta mucho tiempo de CPU ejecutándolos.

Consulte el n. ° 50584 para ver un ejemplo del mundo real en el que cambiar de GNU ld a lld hace que una carga de trabajo común de "cambio menor y reconstrucción" se ejecute más de 2,5 veces más rápido.

Er https://github.com/rust-lang/rust/issues/50584#issuecomment -400918647 es más apropiado aquí:

El siguiente paso para estabilizar LLD sería obtener una bandera, como -Z linker-taste = lld, que funcione para todos los objetivos (Windows + Mac + Linux). Haría lo que sea necesario para funcionar en las distintas plataformas.

Una vez hecho esto, podemos anunciarlo a la comunidad, solicitando comentarios. Aquí podemos obtener tanto información de tiempo como informes de errores para enviar a LLD. Si todo va bien (lo cual es algo dudoso con un enlazador completamente nuevo, ¡pero bueno, nunca se sabe!), Podemos activarlo de forma predeterminada; de lo contrario, podemos trabajar para estabilizar la selección de LLD y luego agregar una opción a Cargo. toml para que los proyectos al menos puedan participar.

Hemos cambiado a lld para algunos objetivos: https://rust-embedded.github.io/blog/2018-08-2x-psa-cortex-m-breakage/

¿Yo también creo en el wasm?

¿Este problema cubre tanto la vinculación con un binario lld externo como la vinculación con el soporte lld interno integrado en el propio rustc? ¿O solo el primero?

¿Este problema cubre tanto la vinculación con un binario lld externo como la vinculación con el soporte lld interno integrado en el propio rustc? ¿O solo el primero?

Solo el binario lld externo, IIUC.

@nnethercote ¿Existe otro problema para rastrear el uso de un enlazador interno, o debo presentar un problema por separado para eso?

No he oído hablar antes de la idea del enlazador interno. No tengo conocimiento de un PR para ello.

https://github.com/rust-lang/rust/pull/57514 terreno preparado para usar LLD para vincular LLVM.

Quizás inicialmente debería haber un término medio entre "predeterminado" y "solo por la noche", alguna forma de optar por usar LLD como podemos con -Z, pero sin usar -Z para que funcione en compilaciones estables.

https://github.com/rust-lang/rust/pull/56351 agregó -C linker-flavor .

No está claro qué se pretende rastrear este problema. Parece que sería mejor cerrar esto a favor de tener problemas específicos, por ejemplo, "Enlace con LLD para objetivos -msvc cuando la cadena de herramientas de Microsoft no está disponible".

Para mí, este problema se trata de habilitar LLD como el vinculador predeterminado para todos los destinos. Me gustaría eso porque LLD es extremadamente rápido y el tiempo de enlace es a menudo un componente importante del tiempo de compilación, y la velocidad de compilación es un problema perenne.

FWIW Presenté un error para admitir LLD en macOS en BMO. Aparentemente eso es WONTFIX. A partir de los comentarios, parece que no es tan simple como "LLD es extremadamente rápido", ya que los LLD en diferentes plataformas son programas diferentes, y el de macOS está roto con el desarrollo estancado.

Estuve de acuerdo con

¿Está documentado el vínculo con LLD en alguna parte? Tengo (en Linux) rustc -C linker-flavor=ld.lld hello.rs , pero no tengo suerte. Pensé que LLD se distribuyó con nuestra copia de LLVM, ¿me equivoco? También intenté instalar LLD a través de apt, pero rustc todavía está desconcertado. ¿Cuáles son los pasos que se deben seguir para probar LLD con código Rust hoy?

@bstrie Además, debe pasar el argumento -C linker=rust-lld .

¿Se supone que funciona con carga? Actualmente recibo los siguientes errores al intentar construir un proyecto en blanco en la última construcción nocturna de óxido y carga.

$ RUSTFLAGS='-C linker=rust-lld' cargo build
   Compiling rust3 v0.1.0 (/home/carado/tmp/rust3)
error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "-L" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.2ualxzb8lqn4ho3y.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.32vfyq64cfbzv618.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.4rbt3m5y8o8cl09t.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.ben0932xzwyt64v.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.fzsdnygvstiwzxo.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.x0rq6ifodcf11zi.rcgu.o" "-o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.1m259ox4uzrzk583.rcgu.o" "--gc-sections" "-pie" "-zrelro" "-znow" "-L" "/home/carado/tmp/rust3/target/debug/deps" "-L" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--start-group" "-Bstatic" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-44988553032616b2.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-607feef6be9150b2.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-a8dbf6d92401e34a.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-9a4716f5e8a3e722.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-988a64d96b043c6d.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-cadd6177b8c6d586.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-8f1d8efc92b45369.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-1e76014677816767.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-cc28bce38cb195d9.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-4123e9e89add689a.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-4d259c17788c1fb5.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-9495dbda85bb8f16.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-793d0026c575805f.rlib" "--end-group" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-33c3162edae6574e.rlib" "-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: rust-lld: error: unable to find library -ldl
          rust-lld: error: unable to find library -lrt
          rust-lld: error: unable to find library -lpthread
          rust-lld: error: unable to find library -lgcc_s
          rust-lld: error: unable to find library -lc
          rust-lld: error: unable to find library -lm
          rust-lld: error: unable to find library -lrt
          rust-lld: error: unable to find library -lpthread
          rust-lld: error: unable to find library -lutil
          rust-lld: error: unable to find library -lutil


error: aborting due to previous error

error: Could not compile `rust3`.

To learn more, run the command again with --verbose.

Recibo los mismos errores que carado. Se logró "shoehorn" -L / usr / lib en la invocación del enlazador, pero eso solo acorta la lista de bibliotecas perdidas a -lgcc que no existe en ninguna parte del sistema como libgcc (hay un libgcc_s.a ) Sospecho que esto es el resultado de algún gnu-ismo, pero no puedo encontrar la manera de solucionarlo.

@almindor prueba RUSTFLAGS='-C linker=rust-lld -L /usr/lib -L /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0' o algo similar. La ruta dependerá de su distribución y versión del compilador.

¿Mi comentario anterior es la forma correcta de usar LLD? No puedo hacer que funcione, ya que todos los programas fallan con SIGSEGV :

Reading symbols from target/debug/hello...
(gdb) show directories
Source directories searched: ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/etc:$cdir:$cwd
(gdb) r
Starting program: target/debug/hello 

Program received signal SIGSEGV, Segmentation fault.
core::ops::function::FnOnce::call_once{{vtable-shim}} () at /rustc/a7f28678bbf4e16893bb6a718e427504167a9494/src/libcore/ops/function.rs:231
(gdb) l
226     #[stable(feature = "fn_once_output", since = "1.12.0")]
227     type Output;
228 
229     /// Performs the call operation.
230     #[unstable(feature = "fn_traits", issue = "29625")]
231     extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
232 }
233 
234 mod impls {
235     #[stable(feature = "rust1", since = "1.0.0")] 
(gdb) info reg
rax            0x0                 0
rbx            0x0                 0
rcx            0x0                 0
rdx            0x0                 0
rsi            0x0                 0
rdi            0x0                 0
rbp            0x0                 0x0
rsp            0x7fffffffddb0      0x7fffffffddb0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
r13            0x0                 0
r14            0x0                 0
r15            0x0                 0
rip            0x7ffff7ffc000      0x7ffff7ffc000 <core::ops::function::FnOnce::call_once{{vtable-shim}}>
eflags         0x10202             [ IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
(gdb) disassemble 
Dump of assembler code for function core::ops::function::FnOnce::call_once{{vtable-shim}}:
=> 0x00007ffff7ffc000 <+0>: mov    (%rdi),%rax
   0x00007ffff7ffc003 <+3>: mov    (%rax),%rdi
   0x00007ffff7ffc006 <+6>: jmpq   *0x11d4(%rip)        # 0x7ffff7ffd1e0
End of assembler dump.

Para cualquiera que termine aquí, el encantamiento mágico es RUSTFLAGS="-C link-arg=-fuse-ld=lld" cargo build si tiene GCC 9 o Clang como compilador. Alternativamente, -C linker=clang debería funcionar independientemente de la versión de GCC, por lo que podría ser preferible.

Para hacerlo permanente, puede agregarlo a ~/.cargo/config o .cargo/config en un proyecto específico:

[build]
rustflags = ["-C", "linker=clang"]
# rustflags = ["-C", "link-arg=-fuse-ld=lld"]

@lnicola tenga en cuenta que solo funciona cuando se usa GCC 9 o Clang como CC.

@bstrie , ¿sabes cuál es el estado actual de esto? ¿Cuáles son los bloqueadores para seguir adelante con eso?

@ mati865 , ¿conoce una invocación alternativa para personas con un CCG más antiguo?

@lnicola todas mis plataformas tienen Clang + GCC 9 y no he investigado cómo usarlo con compiladores incompatibles.

@jonhoo No estoy al tanto del trabajo en esta área, supongo que querrás preguntarle al equipo del compilador.

No creo que pueda marcar equipos, y tampoco quiero causarles ruido indebido. ¿Cuál crees que es la mejor vía para que alguien de allí eche un vistazo rápido?

Triaje; @ rust-lang / compiler, ¿alguien sabe cuál es el estado actual de este problema?

Para cualquiera aquí que logre que LLD trabaje con Rust, ¿puede incluir adicionalmente los detalles sobre su plataforma y las versiones específicas de todos los compiladores que se están utilizando? Sigo viendo a personas en la naturaleza que tienen problemas para hacer que funcione, incluso con los consejos que se enumeran aquí.

El comando que publiqué anteriormente funciona en Linux con GCC 9.2.0 y LLD 9.0.0. Creo que a veces también funciona en Windows, pero he visto a alguien con un GCC 9 para Windows que no es compatible con -fuse = lld. En MacOS no vale la pena intentarlo, según algunos enlaces publicados aquí.

Para cualquiera aquí que logre que LLD trabaje con Rust, ¿puede incluir adicionalmente los detalles sobre su plataforma y las versiones específicas de todos los compiladores que se están utilizando? Sigo viendo a personas en la naturaleza que tienen problemas para hacer que funcione, incluso con los consejos que se enumeran aquí.

cat / etc / system-release
Versión 30 de Fedora (Treinta)

cc --versión
cc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)

ld.lld --versión
LLD 8.0.0 (compatible con enlazadores GNU)

Ojalá esto ayude

pero he visto a alguien con un GCC 9 para Windows que no es compatible con -fuse = lld

@lnicola
Las compilaciones de Windows GCC 9 admiten -fuse-ld=lld (a menos que estén parcheadas para no admitirlo, pero ¿por qué alguien lo haría?).
Supongo que se instaló el componente rust-mingw y el vinculador no se anuló en .cargo/config . De esa manera, rustc eligió GCC 6 que se envía en lugar del sistema.

Otro problema en Windows es el indicador de enlazador codificado --enable-long-section-names que LLD 9 y versiones anteriores no son compatibles (hay planes para admitirlo en el futuro). Para evitar esto, puede:

• crear envoltorio que quita esta bandera
• parche LLD para aceptar esta bandera como no operativa
• use compilaciones locales de Rust parcheadas que no usan esta bandera

Otro problema en Windows es el indicador del vinculador codificado: habilita los nombres de sección larga que LLD 9 y versiones anteriores no admiten (hay planes para admitirlo en el futuro).

Esta parte está arreglada por: https://github.com/rust-lang/rust/pull/66257
Los usuarios de Windows-gnu todavía tienen que hacer trabajo manual para usar el compilador C que admite -fuse-ld=lld .

@bstrie : esto funciona con Stable y Nightly en Windows-MSVC, detalles en la primera publicación de este problema de gamedev-wg: https://github.com/rust-gamedev/wg/issues/50

Otro punto de datos: usar RUSTFLAGS="-C link-arg=-fuse-ld=lld" al construir rustc sí, el tiempo de vinculación cae de 93 a 41 en mi caja Linux rápida de 14 núcleos.

@nnethercote : ¿Es diferente de configurar linker=lld en (por ejemplo) la sección [target.x86_64-unknown-linux-gnu] de config.toml ?

@ Aaron1011 : Supongo que los dos enfoques tienen el mismo efecto, pero no lo he comprobado yo mismo.

@ Aaron1011 debería ser un sonido metálico, consulte https://github.com/rust-lang/rust/issues/39915#issuecomment -538049306.

@ mati865
¿Ha intentado construir rustc en x86_64-pc-windows-gnu con LLD como enlazador?

Lo probé hoy y LLD se cuelga en medio de la compilación y deja de hacer cualquier trabajo, o se queja de unknown argument: --version-script=... .
El bloqueo también ocurre si LLD se usa para vincular LLVM solamente, con

[llvm]
use-linker = "lld"

Versiones de herramientas:

$ ld.lld --version
LLD 9.0.1 (https://github.com/msys2/MINGW-packages.git 5e3b8820ed9f04221affee4197e458aca2612e87) (compatible with GNU linkers)

$ gcc --version
gcc.exe (Rev2, Built by MSYS2 project) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

@petrochenkov sí, podría construirlo con algunos trucos:

• El backend de LLD COFF no admite scripts de enlazado, pero tanto LD como LLD están bien con archivos de estilo MSVC .def ; fácil de resolver
• LLD espera que las bibliotecas comiencen con lib (es un estándar en el mundo UNIX) pero de alguna manera Rust terminó no haciéndolo para todos los objetivos de windows-* : https://github.com/rust-lang/ rust / blob / 9ebf47851a357faa4cd97f4b1dc7835f6376e639 / src / libstd / sys / windows / env.rs # L4
  A LD no le importa de ninguna manera y no sé si presionar en LLD o en el lado de Rust para arreglarlo.

Estoy escribiendo aquí algunas posibilidades futuras. Si bien se necesitan algunos esfuerzos de implementación, creo que estos ayudarán a resolver algunos puntos débiles de larga data en el desarrollo de Rust:

• En lugar de utilizar lld externo proporcionado, compárelo y utilícelo como bibliotecas estáticas dentro de rustc. Esto permite una integración más estrecha con el propio rustc, mejora la experiencia inmediata y abre posibilidades futuras.
• En lugar de pasar muchos nombres de ruta a lld como un comando del enlazador, use un sistema de archivos virtual y pase esos datos de memoria a memoria en lugar de usar E / S de disco siempre que haya suficiente espacio de memoria para hacer. Para proyectos más grandes, esto podría ahorrar cientos o incluso miles de megabytes de E / S de disco y, por lo tanto, mejorar el tiempo de compilación.

En lugar de pasar muchos nombres de ruta a lld como un comando del enlazador, use un sistema de archivos virtual y pase esos datos de memoria a memoria en lugar de usar E / S de disco siempre que haya suficiente espacio de memoria para hacer. Para proyectos más grandes, esto podría ahorrar cientos o incluso miles de megabytes de E / S de disco y, por lo tanto, mejorar el tiempo de compilación.

No es solo una cuestión de ancho de banda de E / S. En plataformas como Windows, especialmente cuando Windows Defender está habilitado, cada archivo con el que desea trabajar agrega una penalización de tiempo bastante significativa, y el modelo de unidad de codegen de Rust significa que las cajas se dividen en cientos de pequeños archivos de objetos que pueden acumular rápidamente una gran cantidad de compilación. tiempo.

Este error es un poco complicado, así que aquí está mi mejor oportunidad de hacer un resumen rápido de la situación actual, para las personas que quieran seguir adelante.

Que es lld

Un enlazador que forma parte del proyecto llvm, que es deseable por dos razones:

• es muy amigable para la compilación cruzada (de ahí su énfasis en los objetivos integrados)
• es muy rápido (a menudo se ejecuta en la mitad del tiempo que Gold; la vinculación puede llevar varios minutos para proyectos grandes (rustc, servo, etc.) y la vinculación puede representar un gran% de la compilación con compilaciones incrementales, por lo que reducir a la mitad este tiempo de ejecución es una Vaya cosa.)

Cosas que Rust hace con lld hoy

• Actualmente, Rust envía su propia copia de lld en la mayoría de las plataformas como un binario que llama rust-lld
• rust-lld se utiliza de forma predeterminada en muchos objetivos de metal desnudo
• rust-lld se usa por defecto para wasm
• (?) puede solicitar explícitamente que se utilice rust-lld mediante el uso de "-C linker-flavour" (confuso en lo que hace exactamente esto en plataformas no bare-metal, ver más abajo)

Problemas para usar rust-lld en más lugares (es decir, escritorio linux / mac / windows)

• El backend de macOS (Mach-O) para lld está roto y abandonado
  
  
  
  • ha comenzado una reescritura desde cero, pero son los primeros días
  
  
• En las plataformas linux / unix, no se supone que debe invocar directamente ld / lld. Se supone que debe invocar el enlazador a través del compilador de su sistema c (es decir, gcc), cuya responsabilidad es descubrir los símbolos del sistema como crt1.o y proporcionárselos a ld. Esto significa que no podemos "simplemente" usar rust-lld; debemos alimentarlo en gcc / clang / lo que sea. (no queremos implementar esta lógica de símbolo del sistema nosotros mismos)
  
  
  
  • En general, no puede proporcionar el vinculador como una ruta, debe inyectarlo en la ruta de búsqueda del compilador de C como "ld"
  
  
  • Alternativamente, puede hacer lo mismo pero inyectarlo como "ld.lld" y pasar "-fuse-ld = lld"
    
    
    
    
    
    • Esto puede ser importante, aparentemente lld detecta el nombre binario de estilo clang si se está ejecutando como "ld" o "ld.lld" (necesita investigación)
    
    
    
    • Desafortunadamente, -fuse-ld = lld es solo una parte de GCC 9, por lo que es posible que necesitemos la detección de características / versiones para usarlo (clang lo ha tenido durante mucho tiempo)
    
    
    
  
  
• windows-msvc aparentemente está en buena forma y parece tener un soporte limitado para usar rust-lld en el backend, pero no tengo claro qué se debe hacer aquí.
• windows-mingw parece estar aproximadamente en el mismo lugar que linux / unix, excepto que es probable que obtengas un GCC antiguo, y las cosas son un poco extrañas porque pseudo-windows-linux no es exactamente una configuración bien probada.

También en general, lld es más nuevo, no es el predeterminado para la mayoría de los sistemas operativos, es casi seguro que surjan errores de compatibilidad aleatoria si comenzamos a usar esto en más lugares.

He presentado dos metabugs para esfuerzos enfocados en el uso de (rust-) lld de forma predeterminada en dos plataformas:

• # 71515 - x64 Ubuntu 20.04 LTS (y más ampliamente todas las plataformas x64 ELF)
• # 71520 - Ventanas x64 msvc

windows-msvc aparentemente está en buena forma y parece tener un soporte limitado para usar rust-lld en el backend, pero no tengo claro qué se debe hacer aquí.

LLD + windows-msvc está en bastante buen estado, actualmente estoy usando esta configuración para el desarrollo rustc .

Todo el soporte necesario para lld-link está en su lugar en rustc backend, pero hay errores como https://github.com/rust-lang/rust/issues/68647.

• Esto puede ser importante, aparentemente lld detecta el nombre binario de estilo clang si se está ejecutando como "ld" o "ld.lld" (necesita investigación)

lo hace, pero ld y ld.lld son el mismo modo: https://github.com/rust-lang/llvm-project/blob/rustc/10.0-2020-02-05/lld/tools/lld/lld. cpp (lo mismo desde el 8.0-2019-01-16)

• Desafortunadamente, -fuse-ld = lld es solo una parte de GCC 9, por lo que es posible que necesitemos la detección de características / versiones para usarlo (clang lo ha tenido durante mucho tiempo)

dado que ld.lld es lo mismo que ld, y de acuerdo con https://patches-gcc.linaro.org/patch/11148/, el único cambio con -fuse-ld = lld es ejecutar ld.lld en lugar de ld, si usamos la inyección PATH, debería estar bien. Sin embargo, creo que bloquear esto en gcc 9+ no es bueno: debian estable solo tiene 8.3, y bullseye probablemente no se lanzará hasta 2021.

• windows-mingw parece estar aproximadamente en el mismo lugar que linux / unix, excepto que es probable que obtengas un GCC antiguo, y las cosas son un poco extrañas porque pseudo-windows-linux no es exactamente una configuración bien probada.

mingw-w64 6.0.0, lanzado 2018-09-16, tiene gcc 8.3.0, que no tiene -fuse-ld = lld, pero sigue siendo razonablemente nuevo. mingw-w64 7.0.0, lanzado 2019-11-11, tiene gcc 9.3.0, que tiene -fuse-ld = lld. Debian buster (estable) tiene 6.0.0, bullseye (prueba) tiene 7.0.0. Debian stretch (oldstable) solo tiene 5.0.1 con gcc 6.3.0, pero creo que sería razonable requerir el último estable de Debian para el soporte de lld si hay problemas importantes con gcc 6.3.

He presentado dos metabugs para esfuerzos enfocados en el uso de (rust-) lld de forma predeterminada en dos plataformas:

• # 71515 - x64 Ubuntu 20.04 LTS (y más ampliamente todas las plataformas x64 ELF)
• # 71520 - Ventanas x64 msvc

Acerca del puerto macOS (Mach-O) de lld: parece funcionar, o al menos, estar en una forma significativamente mejor desde https://github.com/rust-lang/rust/issues/39915#issuecomment -618726211 ¡fue escrito!

Usando esta confirmación LLVM , construí lld y lo configuré como un enlazador específico del proyecto para tokio-rs / tracing . Luego construí el rastreo contra nightly-x86_64-apple-darwin y ejecuté todas las pruebas con éxito. Estoy especialmente feliz por los tiempos de compilación (depuración):

• Con ld , un cargo build limpio tomó 35 segundos.
• Con lld , un cargo build limpio tomó 20 segundos.

Tenga en cuenta que:

• estos números de rendimiento provienen de un MacBook Pro reciente con 32 GB de RAM y un i9 de 8 núcleos, y
• hay algunos problemas pendientes para lld y Mach-O.

@davidbarsky ¡Genial! Por curiosidad, ¿cómo se compara ese rendimiento con zld ? (https://github.com/michaeleisel/zld)

Además, ¿tuvo en cuenta las térmicas? Los MBP entran en estrangulamiento térmico muy rápidamente, especialmente con el perfil de velocidad del ventilador predeterminado. El solo hecho de esperar hasta que la parte inferior de la máquina cerca de la bisagra esté fría al tacto antes de ejecutar una carrera debería ayudar a la consistencia.

Acabo de tal un error, en Ubuntu 16 i686