kdvВ дельфи, если я правильно помню, статической линковки нет, есть только раннее и позднее связывание. Либо мы тупо компилируем код прямо в exe (если этот код есть в виде pas или dcu).
Схематично, можно объяснить примерно так:

Есть 2 стадии для получения бинарика:
1. Компиляция исходного кода в объектные файлы (в случае делфей - из .pas получается .dcu )
На этом этапе текст переводится в код. И создаётся справочник внешних (для файла) имён.

2. Сборка объектных файлов в выходной бинарик - линковка (в случае делфей - из кучи .dcu получается .exe | .dll | .bpl )
Весь код и данные собираются в единые секции а внешние имена заменяются на их адреса в секциях.
Кстати, именно поэтому получить имя функции и стек вызова во время исполнения - нетривиальная задача - имён просто не содержится в бинарике, если нет отладочной информации - спец. секции где сохраняется соответствие имён с адресами.

Для удобства кучку объектных файлов можно собрать в один - библиотеку (не помню как в делфях оно называется .dcl & .bpi ? ), и потом подключать её. Тогда линкер вытащит из неё только нужные для сборки объектники.

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

И дополнительная стадия на этапе загрузки бинарика в память:
3. При загрузке в память системный загрузчик просматривает секцию бинарика, которая содержит имена нужных динамических библиотек, загружает каждую в память (если ещё не загружена) и подставляет реальные адреса экспортных из них символов вместо переходников.

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

Кстати, если понять что происходит на стадиях 2 и 3, то становится понятно что такое dll hell и на что нарвался __Avenger__.
В бинарике содержится только имя внешней .dll -ки, и ничего нет про версию. Поэтому если система ищет по имени, и грузит/берёт первую подходящую.
Если она оказалась не более старая/новая и с другим составом экспортов - происходит ошибка загрузки.
Кстати, гораздо хуже будет если состав экспортов не поменялся, а вот например порядок и/или состав параметров вызова поменялся.
Тут ошибка загрузки не произойдёт но при вызове таких функций случится что попало. Хорошо ещё если сразу сегфолт. :)

П. С. Ежели кому интересно, обсуждать можно в ЖЖ . :)

MaratIsk,

.DCU - это тоже объектные файлы. :)
У продуктов Борланда свой формат объектников, через это Дельфя понимает только объектники полученные от борландёвых же компиляторов.
Так же как и Билдер понимает .dcu-шки от Делфей, но не поймёт что делать с объектниками от FPC или M$ .
А "статические библиотеки" - это не что иное как некоторое количество объектных файлов собранных в один для удобства.
Загляни в директорию bin - там есть утилита для работы со статическими библиотеками. Можно создать либку, долбавить/удалить/заменить объектник в ней.

Таким образом, ехе-шка/dll-ка/bpl-ка получается статическим связыванием (линковкой) объектных файлов (возможно из состава библиотеки).
Кстати, bpl-ка с точки зрения системы ничем не отличается от dll-ки

Динамическое связывание происходит в 2 приёма:
1. ехе-шка/dll-ка статически связывается (линкуется) с библиотекой переходников.
Тут можно заметить, что борландовский линкер умеет автоматом создавать такие библиотеки, если ему подсунуть dll-ку вместо lib-ки.

2. При загрузке в память загрузчик операционки находит требуемые dll-ки, загружает их в память, находит нужные имена или ординалы и подставляет их адреса вместо переходников.