Как библиотеки/включать работают?

configure генерирует a 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 не запускается с нуля, потому что это сохраняет кэш.