Использование архивных файлов для компиляции: почему и есть ли альтернатива?

Question

В середине компиляции ядро ​​Linux создает liba.a, который содержит множество built-in.o и других объектных файлов из разных каталогов, и использует его в качестве основного компонента окончательной ссылки vmlinux. Я видел аналогичное использование архивных файлов при компиляции glibc, и теперь мне интересно, почему в этих проектах используются архивные файлы и что для этого будет полезно.

Насколько мне известно, архивные файлы, созданные с помощью ar, являются просто контейнерами для отдельных включенных в них файлов. Я не вижу большой пользы от его использования, кроме сокращения времени поиска файлов для каждого из объектных файлов. В этом ли причина использования архивных файлов в процессе компиляции?

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

Answer 1

Re: Я не вижу большой пользы от его использования, кроме сокращения времени поиска файлов для каждого из объектных файлов.

Ваше понимание выгоды не совсем верно.Архивы уменьшают рабочую нагрузку разрешения отдельных символов .

Если вы связываете программу из множества отдельных .o файлов, компоновщик должен рассматривать их все одновременно.Ссылки могут идти в любом направлении.Самый последний .o в командной строке может вызывать функцию в самом первом .o и наоборот.

Это не так (по умолчанию, по крайней мере) с архивами.С архивами функции в более ранних архивах могут ссылаться только на символы, определения которых появляются в более поздних архивах.(Это также связано с традиционным соглашением Unix, почему параметры компоновщика -l идут в конце командной строки !!! Сначала ваши .o файлы, а затем командная строка.)

Это означает, чточто после появления архива, который определяет символ, вы можете быть уверены, что более поздние архивы больше не будут использовать этот символ.Это означает, что вы можете удалить его из своих структур данных.Вы в основном «сделали», связывая эту конкретную библиотеку;он удовлетворил предыдущие ссылки, и все, что осталось, это удовлетворить его неразрешенные ссылки.Если вы правильно упорядочите процесс компоновки, а программное обеспечение будет хорошо наслоено, вы сможете минимизировать количество выдающихся символов в любое время.

Linux уже более 20 лет, а его система сборки имеет длинный и богатыйистория, как и код.Архивы не использовались изначально;Я думаю, что это началось только в 2.6.Кроме того, зависимости когда-то генерировались сценарием GNU awk.Люди построили ядро ​​на 25 МГц 386 блоках с 4 мегабайтами оперативной памяти, хаха.

Сегодня используются архивы, потому что им нужно было увеличивать ядро.Это не просто так!

Answer 2

Несколько причин, которые мне не нравятся:

Чтобы узнать, что такое Duck sez: «редактор ссылок» («ld»), он же «компоновщик», («man ld») принимает набор скомпилированных объектных файлов (.o файлы) и библиотек («архив», как вы их называете), которые могут быть «статическими» библиотеками (.a файлы) или «общими библиотеками» (.so файлы) и «ссылками»"их в" исполняемый файл "(" программа ").Один сообщает ld, какие библиотеки использовать, указав несколько вхождений опций -l.Представьте себе, что нужно указать несколько тысяч -l параметров, по одному для каждого компонента .o, вместо нескольких десятков или менее, по одному для каждой библиотеки.

Код, относящийся к одной области функциональности, можетбыть помещенным в одну библиотеку для использования и повторного использования другим кодом.Например, /usr/lib/libcrypt.* предоставляет возможности шифрования, /usr/lib/libssl* предоставляет поддерживающий код для Secure Socket Layer и т. Д.

Кроме того, я не знаю, какой момент времени имел в виду Каз, когда он сказал: «Архивы былипервоначально не использовался ... », но« архивы », статические библиотеки, использовались« совсем недавно », как 1983 (!).Я не встречал динамических разделяемых библиотек до начала 90-х годов.