Что означают «статически связанные» и «динамически связанные»?

StackOverflow https://stackoverflow.com/questions/311882

Вопрос

Я часто слышу термины «статически связанные» и «динамически связанные», часто в отношении кода, написанного в C , C ++ или C # . О чем они, что именно они говорят и что они связывают?

Это было полезно?

Решение

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

Первый - это компиляция, которая превращает исходный код в объектные модули.

Второе, связывание, это то, что объединяет объектные модули вместе, чтобы сформировать исполняемый файл.

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

Когда вы статически связываете файл с исполняемым файлом, содержимое этого файла включается во время связывания. Другими словами, содержимое файла физически вставляется в исполняемый файл, который вы запустите.

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

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

Статически связанные файлы «блокируются» для исполняемого файла во время ссылки, поэтому они никогда не изменяются. Динамически связанный файл, на который ссылается исполняемый файл, можно изменить, просто заменив файл на диске.

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

Это и хорошо, и плохо - с одной стороны, это позволяет упростить обновления и исправления ошибок, с другой - может привести к тому, что программы перестанут работать, если обновления несовместимы - это иногда является причиной ужасного "ада DLL" ; что некоторые люди упоминают в этом, что приложения могут быть сломаны, если вы замените динамически связанную библиотеку библиотекой, которая несовместима (кстати, разработчики, которые делают это, должны ожидать, что их выследят и сурово накажут).

<Ч>

В качестве примера давайте рассмотрим случай, когда пользователь компилирует свой файл main.c для статического и динамического связывания.

Phase     Static                    Dynamic
--------  ----------------------    ------------------------
          +---------+               +---------+
          | main.c  |               | main.c  |
          +---------+               +---------+
Compile........|.........................|...................
          +---------+ +---------+   +---------+ +--------+
          | main.o  | | crtlib  |   | main.o  | | crtimp |
          +---------+ +---------+   +---------+ +--------+
Link...........|..........|..............|...........|.......
               |          |              +-----------+
               |          |              |
          +---------+     |         +---------+ +--------+
          |  main   |-----+         |  main   | | crtdll |
          +---------+               +---------+ +--------+
Load/Run.......|.........................|..........|........
          +---------+               +---------+     |
          | main in |               | main in |-----+
          | memory  |               | memory  |
          +---------+               +---------+

В статическом случае вы можете видеть, что основная программа и библиотека времени выполнения C связаны друг с другом во время соединения (разработчиками). Поскольку пользователь обычно не может повторно связать исполняемый файл, он застрял в поведении библиотеки.

В динамическом случае основная программа связана с библиотекой импорта среды выполнения C (то, что объявляет, что находится в динамической библиотеке, но на самом деле не определяет это). Это позволяет компоновщику ссылаться, даже если сам код отсутствует.

Затем во время выполнения загрузчик операционной системы выполняет позднее связывание основной программы с DLL-библиотекой времени выполнения C (динамическая библиотека ссылок или разделяемая библиотека или другая номенклатура).

Владелец среды выполнения C может в любой момент добавить новую DLL-библиотеку, чтобы предоставить обновления или исправления ошибок. Как указывалось ранее, это имеет как преимущества, так и недостатки.

Другие советы

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

Когда вы компилируете некоторый код C (например), он переводится на машинный язык. Просто последовательность байтов, которая при запуске заставляет процессор складывать, вычитать, сравнивать, «переходить», считывать память, записывать память и все такое. Этот материал хранится в объектных (.o) файлах.

Теперь, давным-давно, ученые-компьютерщики изобрели эту «подпрограмму». вещь. Выполнить-это-кусок-оф-кода и обратный-сюда. Вскоре они поняли, что наиболее полезные подпрограммы могут храниться в специальном месте и использоваться любой программой, которая в них нуждается.

Теперь в первые дни программистам приходилось указывать адрес памяти, на котором были расположены эти подпрограммы. Что-то вроде CALL 0x5A62 . Это было утомительно и проблематично, если эти адреса памяти нужно когда-либо менять.

Итак, процесс был автоматизирован. Вы пишете программу, которая вызывает printf () , а компилятор не знает адрес памяти printf . Таким образом, компилятор просто пишет CALL 0x0000 и добавляет примечание к объектному файлу, в котором говорится, что " необходимо заменить это 0x0000 на место в памяти printf ".

Статическая связь означает, что программа компоновщика (GNU-программа называется ld ) добавляет printf прямо в вашем исполняемом файле и заменяет 0x0000 на адрес printf . Это происходит при создании вашего исполняемого файла.

Динамическая связь означает, что вышеописанный шаг не происходит. В исполняемом файле still есть примечание, в котором говорится, что " должен заменить 0x000 на место в памяти printf " ;. Загрузчик операционной системы должен найти код printf, загрузить его в память и исправить адрес CALL при каждом запуске программы .

Программы обычно вызывают некоторые функции, которые будут статически связаны (стандартные функции библиотеки, такие как printf , как правило, статически связаны) и другие функции, которые динамически связаны. Статические "становятся частью" из исполняемых и динамических "соединяются в" когда исполняемый файл запущен.

У обоих методов есть свои преимущества и недостатки, а также различия между операционными системами. Но так как вы не спросили, я закончу это здесь.

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

Поскольку ни один из вышеперечисленных постов на самом деле не показывает, как статически связать что-либо и увидеть, что вы сделали это правильно, я решу эту проблему:

Простая программа на C

#include <stdio.h>

int main(void)
{
    printf("This is a string\n");
    return 0;
}

Динамически связывать программу C

gcc simpleprog.c -o simpleprog

И запустите файл в двоичном файле:

file simpleprog 

И это покажет, что оно динамически связано с чем-то вроде:

" simpleprog: исполняемый 64-разрядный LSB ELF, x86-64, версия 1 (SYSV), динамически связанный (использует общие библиотеки), для GNU / Linux 2.6.26, BuildID [sha1] = 0xf715572611a8b04f686809d90d1c0d75c6028f0f; не удален

Вместо этого давайте на этот раз статически свяжем программу:

gcc simpleprog.c -static -o simpleprog

Запуск файла в этом статически связанном двоичном файле покажет:

strace ./simpleprog

" simpleprog: исполняемый 64-битный LSB ELF, x86-64, версия 1 (GNU / Linux), со статической связью, для GNU / Linux 2.6.26, BuildID [sha1] = 0x8c0b12250801c5a7c7434647b7dc65a644d6132b, не удален / p; >

И вы можете видеть, что он счастливо статически связан. К сожалению, однако, не все библиотеки просты для статического связывания таким образом и могут потребовать дополнительных усилий, используя libtool или связывая объектный код и библиотеки C вручную.

К счастью, многие встроенные библиотеки C, такие как musl , предлагают варианты статического связывания почти для всех , если не для всех своих библиотек.

Теперь strace созданный вами двоичный файл, и вы можете видеть, что до запуска программы нет библиотек:

<*>

Теперь сравните с выводом strace для динамически связанной программы, и вы увидите, что в статически связанной версии strace намного короче!

(я не знаю C #, но интересно иметь концепцию статической компоновки для языка виртуальных машин)

Динамическое связывание включает в себя умение находить необходимые функции, на которые у вас есть только ссылки из вашей программы. Вы выполняете язык или ОС во время поиска фрагмента кода в файловой системе, сети или кеше скомпилированного кода, сопоставляя ссылку, а затем предпринимаете несколько мер для его интеграции в образ вашей программы в памяти, например перемещение. Все они сделаны во время выполнения. Это может быть сделано либо вручную, либо компилятором. Существует возможность обновления с риском испортить (а именно DLL ад).

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top