Как получить список путей в /etc/ld.so.conf в Linux
Какой самый портативный и надежный способ получить список путей, настроенный /etc/ld.so.conf а файлы из него включены? Парсинг файла вручную, кажется, не очень хорошая идея - формат, вероятно, изменится в будущих версиях.
Чтобы лучше понять вопрос, я дам вам конкретные детали ниже. Обратите внимание, что, несмотря на эти детали, это общий вопрос программирования, применимый к другим ситуациям.
Есть программа, которая называется LuaRocks. Это менеджер пакетов для языка программирования Lua (что-то вроде Ruby gems или Python eggs). Пакеты LuaRocks называются "скалами".
В качестве удобной функции LuaRocks позволяет автору рок-проекта указывать список внешних зависимостей для рок-файла, сформулированный в виде списка заголовочных файлов C и / или файлов динамических библиотек. (.so в Linux.) Если указанный файл не существует, рок не может быть установлен.
В настоящее время в Linux LuaRocks по умолчанию проверяет наличие.so файла, ища файл по двум жестко закодированным путям, /usr/lib а также /usr/local/lib,
Я считаю, что это неправильное поведение, и оно нарушается недавними изменениями в Ubuntu и других дистрибутивах Debian.
Обновление: пути не жестко заданы как таковые, но настраиваются пользователем в файле конфигурации. Тем не менее, ИМО, не лучшее решение.
Вместо этого (насколько я понимаю), LuaRocks должен искать файл в пути, указанном /etc/ld.so.conf и файлы, включенные из него.
(Теперь, пожалуйста, перечитайте вопрос выше;-))
2 ответа
Вам не нужно анализировать /etc/ld.so.conf или любой из файлов конфигурации - если вы запустите 'ldconfig', он будет сканировать настроенные каталоги и сгенерирует файл кэша.
Затем, когда вы попытаетесь выполнить dlopen, он автоматически найдет файлы, просматривая каталоги из кэшированной библиотеки. То же самое с компиляцией и передачей -lSomeLib, вам не нужно указывать -L/my/other/path, если вы настроили его в ld.so.conf (.d)
autoconf выполняет это, пытаясь скомпилировать тестовую программу, которая ссылается на общую библиотеку, но это всего лишь функциональная оболочка для вызова dlopen().
Таким образом, хотя другие методы не обязательно могут быть "неправильными", в основе их лежит попытка установить связь с библиотекой или выполнить dlopen(), что является "наиболее правильным" способом сделать это.
Учтите это, если вы попытаетесь связаться с библиотекой в каталоге, который НЕ кешируется в /etc/ld.so.cache, при попытке запустить программу она потерпит неудачу, потому что она не сможет dlopen() библиотека!
Следовательно, любая "хорошая" разделяемая библиотека будет находиться в /etc/ld.so.cache и иметь возможность linkable/dlopen(), это означает, что gcc может использовать ее для связи и что сгенерированная пользователем библиотека или исполняемый файл сможет откройте его, когда он запустится.
Вы можете обойти это, явно установив переменную окружения LD_LIBRARY_PATH или LD_PRELOAD_PATH - но у каждого из них есть свои предостережения, и их следует избегать, если возможно, для "стандартного" использования.
Хорошая статья о написании разделяемых библиотек охватывает некоторые из этих проблем и хороша для тех, кто работает над программным использованием других совместно используемых библиотек. Ульрих Дреппер. Как писать общие библиотеки.
Согласно FHS, следующие допустимые местоположения для динамических библиотек:
/lib*/
/opt/*/lib*/
/usr/lib*/
/usr/local/lib*/
(И скорее всего ~/lib*/ также.)
Все записи в моем /etc/ld.so.conf.d/* соответствовать этому. Некоторые записи ссылаются на подкаталоги ниже директорий FHS, что, вероятно, означает, что вы можете использовать там библиотеки без информации о пути.
Теперь я не знаю достаточно о LuaRocks. Если вы ограничены шарами в стиле Lua-path (только ?), вы не можете сопоставить их и должны проанализировать конфиги. В противном случае, вы можете просто попытаться найти их где-нибудь в этих каталогах.
Это может привести к поломке в системах, не соответствующих FHS (только опция: parse config), и если каталог не включен в конфигурацию, установщик может увидеть библиотеки, которые компоновщик не может найти.
Эти два кажутся мне приемлемыми, поэтому я бы просто проигнорировал конфигурацию и посмотрел на эти каталоги.
(Другой возможностью может быть попытка связать библиотеку, это должно автоматически использовать правильный путь. Однако это зависит от платформы и может быть опасным.)