Приложение С++ - следует ли использовать статические или динамические ссылки для библиотек?

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

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

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

Примечания:

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

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

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

Выводы:

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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