Si fuera por cualquier otra biblioteca, pero glibc ... Supongo que no puede haber formas rápidas, porque glibc es el lugar donde las cosas están "codificadas". El glibc se ajusta a la versión de su kernel y su cargador es la instancia con la que realmente hace lo correcto (TM) LD_LIBRARY_PATH.
Quizás la forma correcta es:
LD_LIBRARY_PATH="/opt/myglibc/;..." /opt/myglibc/ld-linux.so.2 the_program`
Sin embargo, no estoy seguro de si esto funciona.
En cualquier caso, creo que usar un glibc alternativo requiere un marco aún para implementar, porque las rutas de búsqueda a veces están conectadas y el glibc siempre tiene que adaptarse a su sistema operativo / kernel, por lo que no puede haber binarios genéricos, IMO. El multiarch de Debian muestra que no es trivial, pero aún se puede hacer. Si uno tuviera algún otro medio de discernir bibliotecas además de la arquitectura de destino.
El sitio web me dio este otro hilo relacionado:
Allí, la respuesta aceptada incluye un enlace a un programa llamado rtldi , que parece resolver el problema de glibc. Es de 2004, por lo que es posible que ya no funcione directamente desde el enlazador, pero tal vez valga la pena analizarlo. Su fuente es GPLv2.
Jehová, Jehová
Una vez, a un amigo mío se le ocurrió la idea de que el uso real de las bibliotecas compartidas está sobrevalorado. Y tiene un punto: las bibliotecas compartidas son buenas para no llenar la memoria de su computadora con duplicados, pero teniendo en cuenta la instancia de la aplicación individual, esto es solo unos pocos MB.
Solo hay unas pocas aplicaciones en las que recurriríamos a acciones como proporcionarles su propio glibc. Ahorrándonos un análisis extenso, llamémoslas "aplicaciones inmediatas", que son de utilidad por sí mismas, en el sentido de hacer el trabajo. Por ejemplo, los navegadores web, los agentes de usuario de correo, los trajes de oficina y los reproductores de música permiten al usuario obtener lo que desea y solo hay unas pocas instancias por usuario. Para retratar el otro lado, los servicios del sistema, los administradores de ventanas, incluso entornos de escritorio completos son muy importantes, pero meramente compatibles y, a menudo, no lo suficientemente poco comunes o críticos, para que las personas estén dispuestas a darles su propio glibc.
El número de "aplicaciones inmediatas" es bastante pequeño, absolutamente por usuario y relativamente comparado con lo que generan los SO y DE "básicos" en estos días. Si las aplicaciones inmediatas, como Chrome, Firefox se compilaran estáticamente, el requisito de memoria adicional para el sistema promedio sería de unos 100 MB. Un argumento que no llega muy lejos en los muchos sistemas GB actuales, por lo que la vinculación estática para aplicaciones inmediatas puede ser una opción.
También existen los conceptos de espacio de intercambio y SSD que permiten un intercambio / salida ridículamente rápido, lo que también ayuda a manejar el requisito de memoria aumentada.
El problema de glibc discutido aquí no se resuelve realmente a través del enlace estático, pero para aplicaciones como el navegador web es concebible una especie de formato de distribución autónomo, donde el protocolo X, algunos demonios de sonido y algunos métodos de kernel son la única interfaz. La ventaja sería menos incompatibilidades de versión de biblioteca.
du -h /lib), tenga en cuenta que si se compilaran estáticamente, esa cantidad de RAM sería necesaria para cada y cada aplicación compilada con ellos. Entonces si, por ejemplo. tienes dos aplicaciones que usan la misma pila de biblioteca, ahora necesitarás el doble de memoria. Tres aplicaciones? Tres veces más. Sin mencionar que negaría en gran medida los beneficios del almacenamiento en caché ...