linux - comandos - como cambiar de ip en ubuntu

¿La conexión estática de Linux está muerta? (5)

Con respecto a ese hecho, ¿hay alguna manera 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í, la vinculación estática está muerta en los sistemas GNU. (Creo que murió durante la transición de libc4 / libc5 a libc6 / glibc 2.x.)

La característica fue considerada inútil a la luz de:

Vulnerabilidades de seguridad. La aplicación que estaba enlazada estáticamente ni siquiera es compatible con la actualización de libc. Si la aplicación se vinculó en un sistema que contiene una vulnerabilidad lib, entonces se perpetuará en el ejecutable enlazado estáticamente.
Código de hinchazón. Si muchas aplicaciones enlazadas estáticamente se ejecutan en el mismo sistema, las bibliotecas estándar no se volverían a utilizar, ya que cada aplicación contiene dentro de su propia copia de todo. (Pruebe du -sh /usr/lib para comprender el alcance del problema).

Intente buscar archivos de listas de correo LKML y glibc de hace 10-15 años. Estoy bastante seguro de que hace mucho tiempo que he visto algo relacionado con LKML.

De hecho, la bandera gcc estática en Linux no funciona ahora. Permítanme citar de las FAQ de GNU libc:

2.22. Incluso los programas vinculados estáticamente necesitan algunas bibliotecas compartidas que no son aceptables para mí. ¿Que puedo hacer?
{AJ} NSS (para más detalles solo escriba `info libc" Name Service Switch "'') no funcionará correctamente sin las bibliotecas compartidas. NSS permite utilizar diferentes servicios (por ejemplo, NIS, archivos, db, hesiod) simplemente cambiando un archivo de configuración (/etc/nsswitch.conf) sin volver a vincular ningún programa. La única desventaja es que ahora las bibliotecas estáticas necesitan acceder a bibliotecas compartidas. Esto se maneja de forma transparente por la biblioteca C de GNU.
Una solución es configurar glibc con --enable-static-nss. En este caso, puede crear un binario estático que usará solo los servicios dns y archivos (cambie /etc/nsswitch.conf por esto). Debe vincular explícitamente todos estos servicios. Por ejemplo:
gcc -static test-netdb.c -o test-netdb / -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group
El problema con este enfoque es que debe vincular todos los programas estáticos que usan rutinas NSS con todas esas bibliotecas.
{UD} De hecho, ya no se puede decir que una libc compilada con esta opción usa NSS. Ya no hay interruptor. Por lo tanto, se recomienda encarecidamente no utilizar --enable-static-nss ya que esto hace que el comportamiento de los programas en el sistema sea incoherente.

Con respecto a ese hecho, ¿hay alguna manera 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? Me refiero a la construcción estática que:

Se comporta exactamente de la misma manera que la compilación dinámica (¡static-nss con comportamiento incoherente es malo!);
Funciona con variaciones razonables del entorno glibc y las versiones de Linux;

Agregando otras respuestas:

Debido a las razones expuestas en las otras respuestas, no se recomienda para la mayoría de las distribuciones de Linux, pero en realidad existen distribuciones que se realizan específicamente para ejecutar binarios enlazados estáticamente:

De la descripción de stali:

static linux se basa en una colección seleccionada a mano de las mejores herramientas para cada tarea y cada herramienta está enlazada estáticamente (incluidos algunos clientes X como st, surf, dwm, dmenu),
También se dirige a la reducción de tamaño binario evitando glibc y otras bibliotecas GNU infladas donde sea posible (los primeros experimentos muestran que los binarios vinculados estáticamente son generalmente más pequeños que sus contrapartes glibc dinámicamente vinculadas !!!). Tenga en cuenta que esto es muy contrario a lo que Ulrich Drepper reconoce sobre la vinculación estática.
Debido al beneficio lateral de que los binarios enlazados estáticamente comiencen más rápido, la distribución también se enfoca en ganancias de rendimiento.

El enlace estático también ayuda a la reducción de la dependencia.

Puede leer más sobre esto en esta pregunta sobre enlaces estáticos vs dinámicos .

Creo que esto es muy molesto, y creo que es arrogante decir que una característica es "inútil" porque tiene problemas para tratar ciertos casos de uso. El mayor problema con el enfoque glibc es que codifica las rutas a las bibliotecas del sistema (tanto gconv como nss), y por lo tanto se rompe cuando las personas intentan ejecutar un binario estático en una distribución de Linux diferente a aquella para la que fue creado.

De todos modos, puedes evitar el problema de gconv al establecer GCONV_PATH para que apunte a la ubicación adecuada, esto me permitió tomar binarios creados en Ubuntu y ejecutarlos en Red Hat.

Los enlaces estáticos no parecen tener mucho amor en el mundo de Linux. Aquí está mi opinión.

Las personas que no ven el atractivo de los enlaces estáticos generalmente trabajan en el ámbito del kernel y el sistema operativo de nivel inferior. Muchos desarrolladores de bibliotecas * nix se han pasado la vida lidiando con los problemas inevitables de tratar de vincular cien bibliotecas en constante cambio, una tarea que hacen todos los días. Eche un vistazo a las autotools si alguna vez quiere saber las backflips con las que se sienten cómodas.

Pero no se debe esperar que todos los demás pasen la mayor parte de su tiempo en esto. La vinculación estática le llevará un largo camino hacia la amortiguación de la rotación de la biblioteca. El desarrollador puede actualizar las dependencias de su software de acuerdo con la programación del software, en lugar de verse obligado a hacerlo en el momento en que aparezcan las nuevas versiones de la biblioteca. Esto es importante para las aplicaciones orientadas al usuario con interfaces de usuario complejas que necesitan controlar el flujo de las muchas bibliotecas de nivel inferior de las que inevitablemente dependen. Y es por eso que siempre seré un fanático de los enlaces estáticos. Si puede vincular estáticamente código C y C ++ portátil compilado de forma cruzada, prácticamente habrá hecho del mundo su ostra, ya que puede entregar más rápidamente software complejo a una amplia gama de dispositivos en constante crecimiento en todo el mundo.

Hay muchas cosas en desacuerdo allí, desde otras perspectivas, y es agradable que el software de código abierto les permita a todos.

Solo porque tenga que enlazarse dinámicamente con el servicio NSS no significa que no pueda vincular estáticamente a ninguna otra biblioteca. Todo lo que las preguntas frecuentes dicen es que incluso los programas vinculados "estáticamente" tienen algunas bibliotecas vinculadas dinámicamente. No es decir que la vinculación estática es "imposible" o que "no funciona".