Зачем создавать файл .a из .o для статических ссылок?
6 ответов
Обычно библиотеки представляют собой коллекции объектных файлов, которые могут использоваться в нескольких программах.
В вашем примере нет никаких преимуществ, но вы могли бы это сделать:
ar rcs liboneandtwo.a one.o two.o
Тогда связывание вашей программы становится проще:
gcc -L. prog.c -loneandtwo
Это действительно вопрос упаковки. У вас есть набор объектных файлов, которые естественным образом образуют набор связанных функций, которые можно повторно использовать в нескольких программах? Если это так, то они могут быть разумно заархивированы в статическую библиотеку, иначе, вероятно, нет никакого преимущества.
Есть одно важное отличие на последнем этапе компоновки. Любые объектные файлы, которые вы связали, будут включены в окончательную программу. Объектные файлы, находящиеся в библиотеках, включаются только в том случае, если они помогают разрешить любые неопределенные символы в других объектных файлах. В противном случае они не будут связаны с финальным исполняемым файлом.
Всякий раз, когда мне задают этот вопрос (освежители в моей команде), «почему (или иногда даже« что есть ») .a?», Я использую следующий ответ, который использует .zip в качестве аналогии.
«DotAy подобен zip-файлу всех dotOh, которые вы хотели бы связать при сборке exe / lib. Экономия дискового пространства, плюс не нужно вводить имена всех задействованных dotOh».
до сих пор это, кажется, заставило их понять. ;)
Разница будет в размере исполняемого файла, хотя, возможно, не для вашего примера.
При связывании с библиотекой включаются только те биты, которые используются вашим исполняемым файлом. При связывании объектного файла вы берете все целиком.
Например, если ваш исполняемый файл должен включать каждую математическую функцию в математическую библиотеку, когда вы используете только одну, она будет намного больше, чем нужно, и содержит много неиспользуемого кода.
Интересно сравнить это с моделью динамической компоновки Windows. Там ОС должна полностью загрузить все Dll (динамически связанные библиотеки), которые использует ваш исполняемый файл, что может привести к увеличению объема оперативной памяти. Преимущество такой модели заключается в том, что ваш исполняемый файл сам по себе меньше, и связанные DLL могут уже находиться в памяти, используемой другим исполняемым файлом, поэтому их не нужно загружать снова.
При статическом связывании библиотечные функции загружаются отдельно для каждого исполняемого файла.
Вы можете поместить коллекцию файлов в файл архива (.a) для последующего повторного использования. Стандартная библиотека - хороший пример.
Иногда имеет смысл организовать большие проекты в библиотеки.
Основное преимущество состоит в том, что когда вам нужно связать, вы можете просто указать одну библиотеку вместо всех отдельных объектных файлов. Также есть небольшое преимущество в управлении файлами: работа с одной библиотекой вместо группы объектных файлов. Одно время это также давало значительную экономию дискового пространства, но текущие цены на жесткие диски делают это менее важным.
Технически результат точно такой же. Обычно вы создаете библиотеки для служебных функций, поэтому вместо того, чтобы кормить компоновщик десятками объектных файлов, вам просто нужно связать библиотеку.
Кстати, совершенно бессмысленно создавать файл .a, содержащий только один. o файл.