C / C ++ этапы сборки - PullRequest
1 голос
/ 14 июля 2011

Может ли кто-нибудь описать, что происходит после стадии связывания библиотек lib_xxxx в системах *nix-like при использовании команд ./configure и make?

Собственно, у меня есть конкретный вопрос:

Что происходит за этапом компоновки в make-файлах по сравнению с простым архивированием необходимых .o объектных файлов?

Итак, я уверен, что, например, любую библиотеку C можно объединить с помощью команды, например: ar r libXYZ.a *.o из папки объектов.

Но я подозреваю, что это не то, что на самом деле делается (потому что make-файлы используют libtool и т. Д., ...).

Какова цель этого и как это делается?


Как насчет этапа компоновки при компиляции C++ библиотек кода (в простом случае, например, когда не требуется межобъектная оптимизация)?

Я подозреваю, что вы также можете поместить полученные объектные файлы в архив и использовать их в качестве статической библиотеки.

Так что же на самом деле скрыто и какова цель этого?

Спасибо.

Ответы [ 5 ]

3 голосов
/ 14 июля 2011

Не все ar утилиты созданы равными.libtool скрывает различные параметры и т. Д., Необходимые для разных наборов инструментов, а также поддерживает создание как общих, так и статических библиотек.

0 голосов
/ 14 июля 2011
So, I'm pretty sure that, for example, any C library can be combined together
using command like: ar r libXYZ.a *.o from the object folder.

But I suspect, that this is not what is actually done
(because the makefiles use libtool, etc, ...).

What's the purpose of that and how is it done?

Цель libtool - скрыть сложность вызова реальных системных библиотечных инструментов (например, ar , нм , ld , lipo и т. Д.), Чтобы сделать пакет более переносимым в POSIX-подобных ОС. Сценарий . / Configure выведет сценарий libtool во время его выполнения. Сопровождающий пакета не имеет для использования libtool (и полагается на ручной вызов собственных инструментов с правильными флагами), но это облегчает работу.

Как вы и подозревали, инструменты командной строки используются для сборки библиотек, но скрыты за libtool . Вы можете узнать больше о том, как это сделать, изучив один из файлов библиотеки .la , выведенный libtool , но это только часть ответа. Остальная часть ответа зависит от платформы, где библиотеки должны использоваться, поскольку библиотеки могут быть скомпилированы.

What happens behind the linking stage in makefiles compared to simply archiving
the required .o object files?

Опять же, ответ зависит от платформы, где будут использоваться библиотеки. Для статических библиотек обычно достаточно архивировать их с помощью ar . Для динамических библиотек ответ зависит от системы. В сценарий libtool эта информация встроена, поэтому правильная ситуация возникает при вызове make install .

0 голосов
/ 14 июля 2011

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

В большинстве систем UNIXy, кроме OS X, libtool - это просто интерфейс для компилятора и компоновщика. Большая часть того, что происходит за кулисами, это просто (g)cc и ld.

(В OS X libtool - это отдельная утилита, которая используется для создания статических библиотек .a и файлов общей библиотеки .dylib.)

0 голосов
/ 14 июля 2011

Я разместил довольно подробное описание ссылок на здесь

0 голосов
/ 14 июля 2011

В том, что вы только что сказали, есть много разных шагов:

  1. configure - это сценарий оболочки, который устанавливает среду сборки

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

  3. Фактический вызов "компилятора", пожалуй, больше всего вас интересует: предварительная обработка, компиляция, сборка, вы, кажется, довольны этим.

  4. Наконец, связывание: все объектные файлы должны быть превращены в исполняемый файл: компоновщик будет искать одну точку входа (обычно main()). Все символы (то есть функции и глобальные переменные), которые появляются, должны быть заполнены адресом фактического кода, предоставленного в других объектных файлах. После того, как все символы из ваших локальных объектных файлов будут использованы, у вас могут остаться «неопределенные символы», которые нужно подавать из библиотек.

Таким образом, результатом полного связывания обычно является двоичный файл, в котором все имена функций (возможно) были удалены и заменены фактическими адресами (не говоря уже о PIC) кода или ссылками на совместно используемые библиотеки времени загрузки. По сути, ваша первоначальная коллекция объектов больше не видна в связанном двоичном файле. (Современная оптимизация во время соединения может на самом деле очень сильно смешивать и сокращать ваш код.) С другой стороны, статическая библиотека, созданная с помощью ar , представляет собой просто коллекцию необработанных, несвязанных объектов со всеми их неповрежденные символы, которые можно использовать для ссылки.

Хм, это был очень беспокойный обзор обширного предмета, поэтому, естественно, это далеко не полный или репрезентативный, и, вероятно, только частично правильный. Оставьте комментарий, если у вас есть особые проблемы.

...