Вопрос: Как работают библиотеки / объекты?


Я пытаюсь понять, как работают библиотеки. Вот некоторые вопросы, которые у меня есть об этом:

  1. Я загрузил tarball и извлек его. Когда я делаю «./configure», он ищет в предопределенных каталогах то, что я понимаю для определенных файлов библиотеки.

    Что он делает тогда? Он создает make-файл, а make-файл содержит пути к этим библиотекам?

    Затем я делаю «make», он компилирует исходный код и жестко кодирует местоположения библиотек? Я прав?

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

  2. Я выполнил что-то на своем компьютере, чем переместил его на удаленный серверу, исполняемому файлу нужны библиотеки MySQL, сервер имеет MySQL но по какой-то причине при выполнении файла он говорит мне «не может найти libmysqlclient.so.16». Есть ли решение для этого? Есть ли способ узнать где пытается найти этот файл или дать ему другой путь?

    Я не могу скомпилировать его на сервере, так как у него нет компилятора, и у меня нет root для установки пакетов.

  3. Последний вопрос: если в последовательности "./configure","make","make install" команда «make install» является единственной, которая фактически ставит файлы вне каталога, в котором находятся эти файлы?

    Если, например, программное обеспечение будет установлено в / usr / local /, это «make install», команда единственная, которая потребует «sudo» перед этим?

    Позвольте мне убедиться, правильно ли я прав: «./configure» создает Makefile в соответствии с расположением различных файлов в вашей системе. «make» компилирует исходный код в соответствии с этим make-файлом. И «make install» перемещает файлы в соответствующее место.

Спасибо тем, у кого было терпение, чтобы прочитать мои вопросы.


4
2017-07-01 00:59


Источник


еще одна вещь, команда «./configure», перезаписывает ли он Makefile каждый раз? если, например, я запускаю его, и есть ошибка, может ли он нанести какой-либо ущерб или однажды я исправлю ошибку, он просто перезапишет Makefile, и все в порядке? - fiftyeight


Ответы:


configure генерирует Makefile и часто другие файлы, такие как config.cache, Содержимое этих файлов основано на параметрах, которые вы передаете configure и при наблюдении за вашей системой. Например, многие программы имеют необязательные компоненты и configure ищет зависимости каждого компонента и генерирует make-файл, который только создает компоненты, для которых у вас есть все зависимости.

Если вы запустите configure а затем измените конфигурацию системы, вы должны сделать make distclean сначала (если программа соответствует обычным соглашениям), чтобы удалить make-файл и configureкэш. Бег configure снова обычно работает, когда вы хотите передать ему разные аргументы, но не тогда, когда это кэшированные наблюдения о вашей системе.

Что касается библиотек, то configure этап смотрит на то, что у вас есть с точки зрения совместимости источника. Если libfoo2 совместим с исходным кодом libfoo3 но не с libfoo1, и у вас есть libfoo2, то полученный файл make будет работать, создавая двоичный код, связанный с libfoo2 или двоичный код, связанный с libfoo3 но не бинарный, связанный с libfoo1 (компиляция завершилась неудачей из-за несовместимости исходного уровня).

Когда исполняемый файл скомпилирован и связан, требования к версии становятся более точными: для исполняемого файла требуется бинарно-совместимая библиотека (тот же ABI, а не тот же API).

Исполняемые файлы не содержат жесткие коды для библиотек; они жестко называют имена библиотек (-l аргумент для компоновщика), а иногда и путь поиска библиотеки времени выполнения (-rpath), который входит в дополнение к пути поиска по умолчанию целевой системы. Поиск библиотек во время выполнения - это работа динамический компоновщик,

Я рекомендую немного поиграть с ldd а также strace, ldd показывает библиотеки, необходимые исполняемому файлу, и где система их найдет. strace показывает все системные вызовы, которые происходят при загрузке программы; первые из них исходят от динамического компоновщика, который загружает требуемые библиотеки. Вот несколько экспериментов, результаты которых вы должны попытаться понять.

ldd /bin/true
strace /bin/true
perl -pe 's/libc\.so/libc.zz/' </bin/true >broken
chmod +x broken
ldd ./broken
strace ./broken
ln -s /lib/libc.so.6 libc.zz.6
LD_LIBRARY_PATH=. strace ./broken

Подводя итог ответам на ваши конкретные вопросы:

  1. configure проблемы совместимости с исходными кодами жестких кодов. make проблемы с двоичной совместимостью жестких кодов. Месторасположения библиотек определяются во время выполнения.
  2. Если изменилось только местоположение библиотеки, динамический компоновщик, как правило, найдет его (если у вас установлена ​​библиотека в нестандартном месте, пропустите LD_LIBRARY_PATH переменная среды). Если у вас есть только другая версия библиотеки, то это не та же библиотека; вам нужно либо получить библиотеку с версией ABI, с которой скомпилирована ваша программа, либо скомпилировать вашу программу против версии ABI, для которой у вас установлена ​​библиотека.
  3. configure определяет конфигурацию сборки из того, что у вас есть в вашей системе, и аргументы, которые вы передаете. make создает исполняемые и другие биты. make install копирует бит на место; только на этом этапе могут потребоваться повышенные разрешения (если у вас еще нет разрешения на запись в целевой каталог, который вы, например, установили бы в свой домашний каталог).
  4. configure перезаписывает make-файл, но просто перезапускается configure не запускается с нуля, потому что он хранит кеш.

3
2017-07-02 10:13



THANX A LOT для подробного ответа :) - fiftyeight


Я верю, что когда вы ./конфигурируете на одном компьютере, он выводит make-файл, специфичный для этого одного компьютера, а затем, когда вы передаете скомпилированную программу, библиотека не там, где это сделал make-файл (или исполняемый файл), поэтому он выкидывает ошибка. Как вы можете видеть, при настройке требуется не каждая библиотека, которую он проверяет. Поэтому в зависимости от вашей системы он должен сделать другой make-файл. Другим примером этого является то, что у вас есть другая архитектура, для которой требуются разные библиотеки и т. Д.

И да, у вас правильный порядок. «make» - безопасная команда, работающая только в текущем каталоге, sudo в основном требуется для «make install». Плохо не иметь корневых привилегий при установке программного обеспечения.


1
2017-07-01 01:49



Знаете ли вы, что пути библиотек жестко закодированы в exectuable? или есть что-то, что я могу сделать, некоторая команда, чтобы сделать загрузку файла другой библиотекой? - fiftyeight