Как получить список путей в /etc/ld.so.conf в Linux - PullRequest
4 голосов
/ 11 июля 2011

Каков наиболее переносимый и надежный способ получения списка путей, настроенных с помощью /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.

Обновление: пути не являются жестко заданными как таковые, но настраиваются пользователем в файле конфигурации.Тем не менее, IMO, не лучшее решение.

Вместо этого (насколько я понимаю) LuaRocks должен искать файл по путям, указанным /etc/ld.so.conf, и файлы, включенные в него.

(Теперь, пожалуйста, перечитайте вопрос выше ;-))

Ответы [ 2 ]

8 голосов
/ 11 июля 2011

Вам не нужно анализировать /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 - но у каждого из них есть свои предостережения, и их следует избегать, если возможно, для «стандартного» использования.

Хорошая статья о написании разделяемых библиотек охватывает некоторые из этих проблем и хороша для тех, кто работает над программным использованием других совместно используемых библиотек. Ульрих Дреппер. Как писать общие библиотеки .

1 голос
/ 11 июля 2011

Согласно FHS , следующие допустимые местоположения для динамических библиотек:

/lib*/
/opt/*/lib*/
/usr/lib*/
/usr/local/lib*/

(и, скорее всего, ~/lib*/.)

ВсеЗаписи в моем /etc/ld.so.conf.d/* соответствуют этому.Некоторые записи ссылаются на подкаталоги ниже директорий FHS, что, вероятно, означает, что вы можете использовать там библиотеки без информации о пути.

Теперь я не знаю достаточно о LuaRocks.Если вы ограничены шариками в стиле Lua-path (только ?), вы не можете сопоставить их и должны проанализировать конфиги.В противном случае вы можете просто попытаться найти их где-нибудь в этих каталогах.

Это может привести к поломке в системах, не соответствующих FHS (только опция: parse config), и если каталог не включен в конфигурацию, установщикможет видеть библиотеки, которые компоновщик не может найти.

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

...