Приложение C ++ - использовать ли статические или динамические ссылки для библиотек? - PullRequest
13 голосов
/ 19 января 2010

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

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

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

Примечания:

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

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

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

Выводы:

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

Ответы [ 4 ]

11 голосов
/ 19 января 2010

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

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

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

4 голосов
/ 19 января 2010

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

2 голосов
/ 19 января 2010

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

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

1 голос
/ 19 января 2010

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

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

...