Creo que esto es muy molesto, y creo que es arrogante llamar a una característica "inútil" porque tiene problemas para lidiar con ciertos casos de uso. El mayor problema con el enfoque de glibc es que codifica las rutas a las bibliotecas del sistema (gconv y nss) y, por lo tanto, se rompe cuando las personas intentan ejecutar un binario estático en una distribución de Linux diferente a la que fue creado.
De todos modos, puede solucionar el problema de gconv configurando GCONV_PATH para que apunte a la ubicación adecuada, esto me permitió tomar archivos binarios creados en Ubuntu y ejecutarlos en Red Hat.
¡La vinculación estática ha vuelto a aumentar!
- Linus Torvalds está a favor de los enlaces estáticos y expresó su preocupación por la cantidad de enlaces estáticos en las distribuciones de Linux (ver también esta discusión).
- Muchos (¿la mayoría?) Ir Los ejecutables del lenguaje de programación están enlazados estáticamente.
- La mayor portabilidad y compatibilidad con versiones anteriores es una de las razones por las que son populares.
- Otros lenguajes de programación tienen esfuerzos similares para hacer que la vinculación estática sea realmente fácil, por ejemplo:
- Haskell (Estoy trabajando en este esfuerzo)
- Zig (ver aquí para más detalles)
- Distribuciones de Linux configurables / conjuntos de paquetes como NixOS / nixpkgs hacen posible vincular una gran fracción de sus paquetes de forma estática (por ejemplo, su
pkgsStatic
El conjunto de paquetes puede proporcionar todo tipo de ejecutables vinculados estáticamente). - La vinculación estática puede resultar en una mejor eliminación de código no utilizado en el momento del enlace, lo que hace que los ejecutables sean más pequeños.
- libcs como musl hacer que los enlaces estáticos sean fáciles y correctos.
- Algunas grandes industrias de software Los líderes están de acuerdo en esto. Por ejemplo, Google está escribiendo una nueva libc dirigida a la vinculación estática ("admite vinculación estática no PIE y estática-PIE" , "no tenemos la intención de invertir en este momento [en] carga dinámica y compatibilidad con enlaces" ).
Con respecto a ese hecho, ¿hay alguna forma razonable ahora de crear una compilación estática de funcionamiento completo en Linux o la vinculación estática está completamente muerta en Linux?
No sé dónde encontrar las referencias históricas, pero sí, los enlaces estáticos están muertos en los sistemas GNU. (Creo que murió durante la transición de libc4/libc5 a libc6/glibc 2.x.)
La característica se consideró inútil a la luz de:
-
Vulnerabilidades de seguridad. La aplicación que estaba vinculada estáticamente ni siquiera admite la actualización de libc. Si la aplicación se vinculó en un sistema que contenía una vulnerabilidad lib, se perpetuará dentro del ejecutable vinculado estáticamente.
-
Inflación de código. Si muchas aplicaciones vinculadas estáticamente se ejecutan en el mismo sistema, las bibliotecas estándar no se reutilizarían, ya que cada aplicación contiene su propia copia de todo. (Prueba
du -sh /usr/lib
para comprender el alcance del problema).
Intente buscar archivos de listas de correo LKML y glibc de hace 10 o 15 años. Estoy bastante seguro de que hace mucho tiempo vi algo relacionado en LKML.