☰

Где исполняемые файлы C#, работающие на рабочем столе Ubuntu Linux 16.04 и использующие исходный код, ищутся общими объектами DLLImport во время выполнения?

tag-icon • tag-icon compiling environment-variables dynamic-linking shared-library c#
Где исполняемые файлы C#, работающие на рабочем столе Ubuntu Linux 16.04 и использующие исходный код, ищутся общими объектами DLLImport во время выполнения?

Где исполняемые файлы C#, работающие на рабочем столе Ubuntu Linux 16.04 Lenovo Thinkstation, которые используют исходный код, в котором общие объекты DLLImport (so) ищут общие объекты во время выполнения? Даже если общий объект libxyz.so находится в том же подкаталоге, что и подкаталог исполняемого файла C#, я обнаружил, что необходимо экспортировать LD_LIBRARY_PATH, чтобы обеспечить правильное поведение исполняемой программы C#. Почему это так?

Мы заметили, что во время установки многих сторонних программных продуктов Linux, программы установки или скрипты умудряются находить libc.so.6 в подкаталоге /usr/libx86_64-linux-gnu, не требуя от клиента указывать LD_LIBRARY_PATH, содержащий этот подкаталог. Почему это так?

Кроме того, если мы хотим запустить исполняемый файл C# как point and click mono-service, как нам глобально указать LD_LIBRARY_PATH, пока компьютер не перезагрузится, не прибегая к открытию терминала Ubuntu Linux 16.04? Есть ли более элегантный способ, чем передача LD_LIBRARY_PATH в качестве аргумента envp для execle?

решение1

Я постараюсь ответить вам на все три части этого вопроса.

[Почему] необходимо экспортировать LD_LIBRARY_PATH для обеспечения корректного поведения исполняемой программы C#

Программы установки или скрипты находят libc.so.6 в подкаталоге /usr/libx86_64-linux-gnu, не требуя от клиента указания LD_LIBRARY_PATH

Связанные библиотеки ссылаются из известного набора местоположений. Обычно это системные каталоги, чтобы привилегированный код мог безопасно их использовать (пользователи не могут их перезаписывать).

Как только вы это поймете, вы поймете, что набор известных местоположений не может не включать .. Вы можете увидеть набор известных местоположений, изучив текстовый файл /etc/ld.so.conf. Если вы его редактируете, вы должны запустить ldconfig, чтобы обновить его соответствующую двоичную базу данных.

Набор известных расположений может быть расширен для каждого приложения с помощью экземпляра LD_LIBRARY_PATH, который принимает разделенный двоеточием список каталогов для поиска. Однако если вы используете это, ядро ​​отменяет все привилегии программы - поэтому вы не можете использовать его для мошенничества passwdили sudo, например.

как нам глобально указать LD_LIBRARY_PATH, пока компьютер не перезагрузится [...] Есть ли более элегантный способ, чем передача LD_LIBRARY_PATH в качестве аргумента envp в execle?

Установка его глобально была бы очень плохой идеей, так как это сломало бы sudo, passwd, и другие привилегированные программы. Я не понимаю, почему вы не можете установить LD_LIBRARY_PATHскрипт оболочки для каждого приложения. Вам не нужно запускать его как "терминальную программу", так как он не пишет ничего существенного в терминал

#!/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

Я использовал "$@"это так, чтобы любые аргументы, переданные скрипту, применялись к самому исполняемому файлу.

Я не знаю, как вы запустите или остановите моносервис, поэтому не могу помочь вам с подробностями. Если вы обновите свой вопрос, я посмотрю, смогу ли я что-то добавить.

Связанный контент