Linux: стандартная библиотека C / C++ static vs dynamic linking [дубликат]
этот вопрос уже есть ответ здесь:
вероятно, на любой ОС можно скомпилировать стандартную библиотеку C++/C статически или динамически. В Windows я предпочитаю статические сборки всегда, потому что это помогает избежать проблемы "dll hell" с разными версиями библиотеки, установленные или не установленные в определенных версиях Windows, выпусках и пакетах обновления и т. д. Статическое связывание делает программное обеспечение более портативным и менее зависимым от того, что конечный пользователь сделал со своей операционной системой (я даже видел примеры, когда конечный пользователь мог сделать SHIFT+DEL на некоторых DLL в system32, он не мог объяснить, почему или когда пользователи утверждают, что мое приложение содержит вирус, потому что он пытался загрузить динамически связанные предпосылки с официального сайта Microsoft...) Итак, на Windows статическая привязка обычно лучше, чем динамичный, по моему опыту.
Тем не менее, я новичок в Linux, поэтому может ли кто-нибудь поделиться своим опытом? Мой вопрос:какая связь (динамическая или статическая) предлагается в Linux, если мы игнорируем тот факт, что динамическая позволяет экономить память и пространство на жестком диске, и если мы планируем распространять программное обеспечение с автоматической программой установки (место на жестком диске и память теперь достаточно дешевы, поэтому нет причин жертвовать часами рабочего времени, необходимого для создания действительно хорошего и портативный установщик, чтобы выиграть несколько мегабайт ОЗУ или места на жестком диске). Существуют ли какие-либо проблемы с динамической/статической связью для Linux?
4 ответов
в Linux у вас обычно есть менеджер пакетов, который гарантирует, что у вас установлена только одна версия библиотек. Таким образом, обычно нет dll hell и нет проблем с динамической связью. Динамическое связывание является стандартным способом в Linux.
Я бы сказал, что ответ зависит от того, как вы распространять программное обеспечение.
Если вы упаковываете программное обеспечение для конкретного дистрибутива Linux и версии динамической компоновки, как правило, предпочтительнее. Вы знаете, какие библиотеки найти в системе, и вы можете указать зависимости.
однако, если вы хотите распространять программное обеспечение как двоичный файл Linux, который работает на" любой " системе (например, различные игры или программное обеспечение, например, Matlab), вы получите ту же dll (или .так что ... ) адская проблема, как на windows. Вы не знаете, какие версии библиотек в системе. Таким образом, вы должны будете обеспечить свой собственный .так файлы или ссылка статически.
см. весь смысл использования динамической компоновки заключается в уменьшении размера исполняемых файлов и использования памяти.Если вы пренебрегаете этим, то говорить не о чем.
с другой стороны, вы упомянули о сохранении памяти и дискового пространства.Необходимо сохранить дисковое пространство, потому что, когда вы хотите экспортировать приложение/программу, вы не можете поместить приложение 2Gb в интернет для загрузки(например, библиотека openCV составляет около 2,1 ГБ). Решение состоит в том, чтобы динамически связывать их и загружать только эти модули которые вам необходимы.Это также обеспечивает эффективную многозадачность (создает только одну копию модуля, и вся программа использует ту же копию). особенно:
например, приложение media player может быть первоначально отправлено с кодеком, который поддерживает формат MP3. Если бы медиаплеер был статически связан, он бы не можно динамически обновлять его для поддержки другого формата файлов, без замена всего приложения. Динамическая компоновка означает, что новая версия общая библиотека, содержащая более современный кодек, который включает в себя некоторые усовершенствования и исправления ошибок, могут быть динамически загружены динамическим компоновщиком в память во время выполнения чтобы заменить исходную общую библиотеку. Общая библиотека также может использоваться несколькими приложениями. Например, два разные медиаплееры могут использовать одну и ту же общую библиотеку, содержащую одно и то же кодек. Это потенциально означает, что устройство, запускающее приложение, требует меньше физической памяти в зависимости от размера динамического компоновщика.
в-третьих, в linux все динамически связано, за исключением /bin / ash.статический whic также имеет свою динамическую версию / bin / ash, но это не должно останавливать вас от статического связывания в linux. при использовании gcc связь по умолчанию динамическая.Я думаю, вы должны использовать флаг "-static " для статической связи библиотек
@Vitaliy хорошо, что вы об этом заговорили.Здесь важно отметить, что интеллектуальное связывание и создание общих (или динамических) библиотек являются взаимоисключающими, то есть если вы включаете интеллектуальное связывание, то создание общих библиотек отключается.
smart linking разбивает код на небольшие блоки кода, и их зависимости загружаются. Поэтому, если вы вызываете зависимость несколько раз, она загружается несколько раз. Это дает очень хорошее время выполнения, но очень высокое время компиляции, особенно для больших единиц.Так что есть определенный компромисс.