¿Dónde se ejecutan los ejecutables de C# en un escritorio Lenovo Thinkstation Ubuntu Linux 16.04 que utiliza el código fuente que los objetos compartidos (so) de DLLImport buscan objetos compartidos en tiempo de ejecución? Incluso si el objeto compartido libxyz.so reside en el mismo subdirectorio que el subdirectorio del ejecutable de C#, descubrí que es necesario exportar LD_LIBRARY_PATH para garantizar el comportamiento correcto del programa ejecutable de C#. ¿Por qué es este el caso?
Notamos que durante la instalación de muchos productos de software Linux de terceros, los programas o scripts de instalación logran encontrar libc.so.6 en el subdirectorio /usr/libx86_64-linux-gnu sin necesidad de que el cliente especifique una LD_LIBRARY_PATH que contenga ese subdirectorio. ¿Por qué es ese el caso?
Además, si deseamos ejecutar el ejecutable de C# como un monoservicio de apuntar y hacer clic, ¿cómo especificamos globalmente LD_LIBRARY_PATH, hasta que la computadora se reinicie, sin recurrir a abrir una terminal Ubuntu Linux 16.04? ¿Existe una forma más elegante que pasar LD_LIBRARY_PATH como argumento envp para ejecutar?
Respuesta1
Intentaré responder las tres partes de esta pregunta por ti.
[¿Por qué es] necesario exportar LD_LIBRARY_PATH para garantizar el comportamiento correcto del programa ejecutable de C#?
Los programas o scripts de instalación logran encontrar libc.so.6 en el subdirectorio /usr/libx86_64-linux-gnu sin necesidad de que el cliente especifique un LD_LIBRARY_PATH
Se hace referencia a las bibliotecas vinculadas desde un conjunto conocido de ubicaciones. Normalmente, estos son directorios del sistema para que el código privilegiado pueda usarlos de forma segura (los usuarios no pueden sobrescribirlos).
Una vez que comprende esto, se da cuenta de que el conjunto de ubicaciones conocidas no puede no incluir .. Puede ver el conjunto de ubicaciones conocidas examinando el archivo de texto /etc/ld.so.conf. Si lo editas debes ejecutarlo ldconfigpara actualizar su base de datos binaria correspondiente.
El conjunto de ubicaciones conocidas se puede ampliar por aplicación utilizando una instancia de LD_LIBRARY_PATH, que toma una lista de directorios separados por dos puntos para buscar. Sin embargo, si usas esto, el kernel descarta todos los privilegios de un programa, por lo que no puedes usarlo para hacer trampa passwdo sudo, por ejemplo.
¿Cómo especificamos globalmente LD_LIBRARY_PATH, hasta que la computadora se reinicie [...] ¿Existe una forma más elegante que pasar LD_LIBRARY_PATH como argumento envp para ejecutar?
Configurarlo globalmente sería una muy mala idea ya que rompería sudo, passwdy otros programas privilegiados. Sin embargo , no veo por qué no se puede configurar LD_LIBRARY_PATHun script de shell por aplicación. No es necesario iniciarlo como un "programa de terminal", ya que no escribe nada significativo en una terminal.
#!/bin/bash
#
APP_DIR=/path/to/application
APP_DIR_LIB="$APP_DIR/lib"
APP_DIR_EXE="$APP_DIR/someprogram.exe"
export LD_LIBRARY_PATH="$APP_LIB_DIR"${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
exec "$APP_DIR_EXE" "$@"
echo "Ooops" >&2
exit 1
Lo he usado "$@"para que cualquier argumento pasado al script se aplique al ejecutable.
No sé cómo iniciarías o detendrías un servicio mono, así que no puedo ayudarte con los detalles al respecto. Si actualiza su pregunta, veré si hay algo que pueda agregar aquí.