97 этюдов для программистов. Опыт ведущих экспертов

Компоновщик не таит в себе никаких чудес Уолтер Брайт

Удручающе часто (со мной это снова случилось как раз перед написанием этого текста) встречается следующий взгляд программистов на процесс превращения исходного кода на компилируемом языке в статически скомпонованный выполняемый модуль:

1. Отредактировать исходный код.

2. Скомпилировать исходный код в объектные файлы.

3. Происходит волшебство.

4. Запустить исполняемый файл.

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

1. Компоновщик сообщает, что def определен более одного раза.

2. Компоновщик сообщает, что символ abc не найден (unresolved).

3. Почему мой исполняемый файл такой большой?

Затем следует вопрос «Что мне теперь делать?» с вкраплениями слов «вроде бы» и «как-то там», и все это в атмосфере полнейшей озадаченности. Эти «вроде бы» и «как-то там» свидетельствуют о том, что процесс компоновки воспринимается как некое волшебство, понятное только колдунам и чародеям. Процесс компиляции не приводит к формулировкам такого рода, то есть программисты в целом понимают, как работают компиляторы или хотя бы в чем их назначение.

Компоновщик — это тупая, приземленная и прямолинейная программа. Ее задача — склеить область кода и область данных объектных файлов, соединить ссылки на символы с их определениями, выбросить неразрешенные символы из библиотеки и записать исполняемый файл. Все! Никаких чудес и магии! То, что написание компоновщика является утомительным трудом, обычно связано с декодированием и генерацией файлов, формат которых бывает безобразно сложным, но суть компоновщика от этого не меняется.

Итак, допустим, что компоновщик сообщает вам, что def определен более одного раза. Во многих языках программирования, включая C, C++ и D, существуют объявления и определения. Объявления обычно помещаются в файлы заголовков, например:

extern int iii;

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

int iii = 3;

Сколько определений может существовать для каждого символа? Как в фильме «Горец», «в живых останется только один». Что произойдет, если определение iii обнаружится более чем в одном файле реализации?

// Файл a.c 

int iii = 3;

// Файл b.c

double iii(int x) { return 3.7; }

Компоновщик сообщит о неоднократном определении iii.

Определение может быть только одно, более того, оно должно быть обязательно. Если iii появляется только в объявлении, но для него нет определения, компоновщик сообщит о том, что символ iii не найден.

Чтобы выяснить, почему у исполняемого модуля такой размер, взгляните на файл карты (map), который компоновщик может вывести по запросу. Этот файл содержит перечень всех символов в исполняемом модуле с их адресами. Из него вы узнаете, какие модули были взяты из библиотек и их размеры. Теперь станет ясно, почему так раздулась ваша программа. Часто обнаруживаются библиотечные модули, о подключении которых вы и не догадывались. Чтобы разобраться, временно удалите подозрительный модуль из библиотеки и повторите компоновку заново. Ошибка «неопределенный символ» поможет узнать, кто обращается к этому модулю.

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