Приложение C++ - я должен использовать статическое или динамическое подключение для библиотек?
Я собираюсь запустить новый проект C++, который будет полагаться на серию библиотек, включая часть библиотек 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. цикл на своей dev. машине
4 ответа
Статическое связывание имеет плохой рэп. У нас есть огромные жесткие диски в эти дни и необычайно толстые трубы. Многие из старых аргументов в пользу динамического соединения сейчас менее важны.
Плюс, есть одна хорошая причина для предпочтения статической связей на Linux: множество конфигураций платформы из-за того, что она практически невозможна гарантировать, что ваш исполняемый файл будет работать даже на небольшую долю без статического соединения.
Я подозреваю, что это не будет популярным мнением. Отлично. Но у меня есть 11 лет опыта развертывания приложений на Linux, и пока что-то вроде LSB действительно не вылетает и действительно расширяет его досягаемость, Linux будет продолжать намного сложнее для развертывания приложений. До тех пор статически ссылается на ваше приложение, если вам нужно пройти через широкий ассортимент платформ.
Я бы, вероятно, использовал бы динамическое связывание во время (большинство) разработки, а затем перейти к статическому соединению для окончательных этапов разработки и (все) развертывания. К счастью, для дополнительного тестирования мало потребностей при переключении от динамической к статической связи библиотек.
Это еще одно голосование за статическое соединение. Я не заметил, что значительно более длительное время связывания для внесения приложения. Обеспечение приложения - это приложение Line Console ~ 50k, с несколькими библиотеками, которые скомпилированы для кучка из обычных машин, в основном суперкомпьютеров с 100-10 000 сердечников. С статической связью вы точно знаете, какие библиотеки вы собираетесь использовать, могут легко проверить новые версии из них.
В общем, это способ, которым большинство приложений Mac созданы. Это то, что позволяет установить просто копировать каталог на систему.
Лучше всего оставить это до Packager и предоставить оба параметра в настройках / создании сценариев. Обычно динамическое связывание будет иметь предпочтение с тех пор, как это было бы легко обновить библиотеки, когда это необходимо, когда обнаружены уязвимости безопасности и т. Д.
Обратите внимание, что если у вас нет привилегий root, чтобы установить библиотеки в системных каталогах, вы можете компилировать такую программу, которую она сначала будет выглядеть в другом месте для любых необходимых динамических библиотек, это достигается, установив директиву RunPath в двоичных файлах ELF. Вы можете указать такой каталог с опцией -RPath из линкера ld.