Onde os executáveis C # em execução em um desktop Ubuntu Linux 16.04 Lenovo Thinkstation que usam código-fonte para que os objetos compartilhados do DLLImport (so's) procurem objetos compartilhados em tempo de execução? Mesmo que o objeto compartilhado libxyz.so resida no mesmo subdiretório do subdiretório do executável C#, descobri que é necessário exportar LD_LIBRARY_PATH para garantir o comportamento correto do programa executável C#. Por que isso acontece?
Observamos que durante a instalação de muitos produtos de software Linux de terceiros, os programas ou scripts de instalação conseguem encontrar libc.so.6 no subdiretório /usr/libx86_64-linux-gnu sem exigir que o cliente especifique um LD_LIBRARY_PATH contendo esse subdiretório. Por que isso acontece?
Além disso, se desejarmos executar o executável C# como um mono-serviço apontar e clicar, como especificamos globalmente LD_LIBRARY_PATH, até que o computador seja reinicializado, sem recorrer à abertura de um terminal Ubuntu Linux 16.04? Existe uma maneira mais elegante do que passar LD_LIBRARY_PATH como um argumento envp para executar?
Responder1
Tentarei responder a todas as três partes desta pergunta para você
[Por que é] necessário exportar LD_LIBRARY_PATH para garantir o comportamento correto do programa executável C#
programas ou scripts de instalação conseguem encontrar libc.so.6 no subdiretório /usr/libx86_64-linux-gnu sem exigir que o cliente especifique um LD_LIBRARY_PATH
Bibliotecas vinculadas são referenciadas a partir de um conjunto conhecido de locais. Normalmente, esses são diretórios do sistema para que o código privilegiado possa usá-los com segurança (eles não podem ser substituídos pelos usuários).
Depois de entender isso, você percebe que o conjunto de locais conhecidos não pode deixar de incluir .. Você pode ver o conjunto de locais conhecidos examinando o arquivo de texto /etc/ld.so.conf. Se você editá-lo você deve executar ldconfigpara atualizar seu banco de dados binário correspondente.
O conjunto de locais conhecidos pode ser estendido por aplicativo usando uma instância de LD_LIBRARY_PATH, que usa uma lista de diretórios separados por dois pontos para pesquisar. Porém, se você usar isso, o kernel descarta todos os privilégios de um programa - então você não pode usá-lo para trapacear passwdou sudo, por exemplo.
como especificamos globalmente LD_LIBRARY_PATH, até que o computador seja reinicializado [...] Existe uma maneira mais elegante do que passar LD_LIBRARY_PATH como um argumento envp para executar?
Defini-lo globalmente seria uma péssima ideia, pois quebraria sudo, passwde outros programas privilegiados. Não vejo por que você não pode definir LD_LIBRARY_PATHum script de shell por aplicativo. Você não precisa iniciá-lo como um “programa de terminal”, pois ele não grava nada significativo em um 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
Usei "$@"para que quaisquer argumentos passados ao script sejam aplicados ao próprio executável.
Não sei como você iniciaria ou interromperia um serviço mono, então não posso ajudá-lo com os detalhes disso. Se você atualizar sua pergunta, verei se há algo que possa acrescentar aqui.