Приложение C++ – следует ли использовать статическую или динамическую компоновку библиотек?

Question

Я собираюсь начать новый проект C++, который будет опираться на ряд библиотек, включая часть библиотек Boost, log4cxx или библиотеку журналов Google, а по мере развития проекта также будут использоваться и другие (чего я пока не могу предвидеть). .

Ему придется работать как на 32-, так и на 64-битных системах, скорее всего, в довольно разнообразной среде Linux, где я не ожидаю, что будут доступны все необходимые библиотеки и привилегии su.

Мой вопрос: следует ли мне создавать свое приложение, динамически или статически связываясь со всеми этими библиотеками?

Примечания:

(1) Я знаю, что статическое связывание может быть проблематичным во время разработки (увеличение времени компиляции, кросс-компиляция как для 32-, так и для 64-разрядных версий, переход по цепочкам зависимостей для включения всех библиотек и т. д.), но во время тестирования это намного проще - просто переместите файл и запустите.

(2) С другой стороны, динамическое связывание становится проще на этапе разработки - короткое время компиляции (я действительно не знаю, как обрабатывать динамическое связывание с 64-битными библиотеками из моей 32-битной среды разработки), никакой суеты с цепочками зависимостей.С другой стороны, развертывание новых версий может быть неприятным, особенно когда требуются новые библиотеки (см. выше условие отсутствия прав su на целевых машинах или доступности этих библиотек).

(3) Я прочитал соответствующие вопросы по этой теме, но не смог понять, какой подход лучше всего соответствует моему сценарию.

Выводы:

1. Спасибо всем за ваш вклад!
2. Я, вероятно, выберу статическое связывание, потому что:
• Более простое развертывание
• Предсказуемая производительность и более стабильные результаты во время тренировок.тестирование (см. эту статью:http://www.inf.usi.ch/faculty/hauswirth/publications/CU-CS-1042-08.pdf)
• Как уже отмечалось, размер и продолжительность компиляции статических и статистических файлов.в динамике вроде бы не такая уж большая разница
• Более простые и быстрые циклы испытаний
• Я могу сохранить все разработки.цикл на моем dev.машина

Answer 1

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

Кроме того, есть одна действительно веская причина предпочесть статическое связывание в Linux:Из-за множества конфигураций платформ практически невозможно гарантировать, что ваш исполняемый файл будет работать даже на небольшой их части без статического связывания.

Я подозреваю, что это не будет популярное мнение.Отлично.Но у меня есть 11-летний опыт развертывания приложений в Linux, и до тех пор, пока что-то вроде LSB действительно не станет популярным и действительно не расширит сферу своей деятельности, развертывание приложений на Linux будет по-прежнему гораздо сложнее.А до тех пор статически связывайте свое приложение, если вам придется работать на широком спектре платформ.

Answer 2

Я бы, вероятно, использовал динамическое связывание во время (большинства) разработки, а затем перешел бы на статическое связывание на заключительных этапах разработки и (всего) развертывания.К счастью, при переключении с динамического на статическое связывание библиотек необходимость в дополнительном тестировании невелика.

Answer 3

Это еще один голос в пользу статических ссылок.Я не заметил значительного увеличения времени компоновки нашего приложения.Рассматриваемое приложение представляет собой консольное приложение размером около 50 тыс. строк с множеством библиотек, скомпилированных для множества необычных машин, в основном для суперкомпьютеров со 100–10 000 ядер.Благодаря статическому связыванию вы точно знаете, какие библиотеки собираетесь использовать, и можете легко тестировать их новые версии.

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

Answer 4

Лучше всего оставить это на усмотрение упаковщика и предоставить обе опции в сценариях configure/make.Обычно предпочтение отдается динамическому связыванию, поскольку тогда при необходимости можно будет легко обновить библиотеки, т.е.когда уязвимости безопасности и т. д.обнаружены.

Обратите внимание: если у вас нет прав root для установки библиотек в системные каталоги, вы можете скомпилировать программу так, чтобы она сначала искала в другом месте любые необходимые динамические библиотеки. Это достигается путем установки директивы runpath в двоичных файлах ELF.Вы можете указать такой каталог с помощью опции -rpath компоновщика ld.