Приводят ли циклически статические связанные библиотеки к большему выходному размеру? - PullRequest
0 голосов
/ 14 февраля 2019

У меня есть несколько статических библиотек на C ++.Например:

  • lib a
  • lib b
  • lib c

lib a использует lib c и lib c использует a , а b использует оба.У нас есть круговые зависимости между библиотеками.Поскольку они являются статическими библиотеками, размер вывода больше, если они круглые, потому что они включены в b . a включено в c и c в sode, код в b дважды: (

Может кто-нибудьобъясните мне, как это работает?

И если a , b и c будут связаны с d будеткод c внутри d тоже дважды?

Ответы [ 2 ]

0 голосов
/ 14 февраля 2019

Библиотеки статически не связаны друг с другом;они статически связаны с исполняемыми файлами.

Таким образом, не имеет значения, какие библиотеки ссылаются друг на друга - lib a никогда не будет содержать копию lib c (исключая возможность встраивания кода).

Ваш компоновщик при сборке исполняемого файла также будет извлекать каждую зависимую библиотеку только один раз.

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

0 голосов
/ 14 февраля 2019

размер вывода больше [при многократном связывании]?

Нет, размер выходного файла вашего исполняемого файла не меняется в зависимости от порядка ваших библиотек, а также от числараз вы указываете библиотеки.

Может кто-нибудь объяснить мне, как это работает?

При создании исполняемого файла (не библиотеки): компоновщик обычно ссылается на гранулярность файла *.o, что означает, что либо файл * .o включен в исполняемый файл, либо нет.Но каждый *.o файл включается в исполняемый файл только один раз.Вот почему размер не отличается, даже если вы линкаете lib три раза.

А если a, b и c будут связаны с d, то будет ли также код c внутри d дважды?

Статические библиотеки обычно не связаны друг с другом.Они просто перепакованы вместе в новый ar архив.И, как и в случае с исполняемым файлом, каждый файл * .o остается в новой библиотеке (новом архиве ar) только один раз, поэтому размер не увеличивается, даже если вы добавляете библиотеку дважды, прямо или косвенно.

Уменьшение размера исполняемого файла: Если вас беспокоит размер вашего исполняемого файла и вы используете gcc или LLVM, есть хороший способ уменьшить его:

  • Скажите gcc о размещении каждой отдельной функции в отдельном разделе: -ffunction-sections

  • Затем сообщите компоновщику мусорной корзине (откажитесь) от неиспользуемых разделов: -Wl,--gc-sections

Удивительно, что это не по умолчанию.Без этих параметров всегда весь файл *.o присутствует в исполняемом файле, если есть ссылка хотя бы на одну вещь в этом файле *.o.Неиспользуемые *.o файлы также всегда удаляются (если не указаны конкретные параметры), но не на уровне функций.

Связывание динамических библиотек (общих объектов, DSO, как вы хотите их вызывать) сновадругое дело в системах UNIX и более сложное.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...