Рекомендации по отладке ошибок связывания

Question

При создании проектов на C ++ я обнаружил, что отладка ошибок компоновки сопряжена с трудностями, особенно при использовании чужого кода.Какие стратегии люди используют для отладки и исправления ошибок компоновки?

Answer 1

Не уверен, каков ваш уровень знаний, но вот основы.

Ниже приведена ошибка компоновщика из VS 2005 - да, это огромная путаница, если вы с ней не знакомы.

ByteComparator.obj : error LNK2019: unresolved external symbol "int __cdecl does_not_exist(void)" (?does_not_exist@@YAHXZ) referenced in function "void __cdecl TextScan(struct FileTextStats &,char const *,char const *,bool,bool,__int64)" (?TextScan@@YAXAAUFileTextStats@@PBD1_N2_J@Z)

Есть пара моментов, на которых следует заострить внимание:

• "ByteComparator.obj" - Найдите файл ByteComparator.cpp, это источник проблемы компоновщика
• "int __cdecl does_not_exist(void)" - Это символ, который он не смог найти, в данном случае функция с именем does_not_exist()

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

Если вы используете VS2005, вы бы воспользовались контекстным меню "Зависимости проекта ...".Если вы используете gcc, вам следует поискать в своих makefiles шаг генерации исполняемого файла (gcc вызывается с кучей файлов .o) и добавить отсутствующий файл .o.

---

Во втором сценарии вам может не хватать "внешней" зависимости, для которой у вас нет кода.Библиотеки Win32 часто реализуются в статических библиотеках, на которые вам приходится ссылаться.В этом случае перейдите к MSDN или "Microsoft Google" и выполните поиск API.В нижней части описания API указано название библиотеки.Добавьте это в список свойств вашего проекта "Свойства конфигурации-> Компоновщик-> Ввод-> Дополнительные зависимости".Например, функция timeGetTime()'s страница в MSDN в нижней части страницы указано, что вам нужно использовать Winmm.lib.

Answer 2

Библиотеки C-runtime часто являются главными виновниками. Убедиться, что все ваши проекты имеют одинаковые настройки: одиночная или многопоточность, статическая - dll.

Документация MSDN хороша для указания того, какую библиотеку требует конкретный вызов API Win32, если он обнаружен как отсутствующий.

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

Answer 3

Одна из распространенных ошибок связывания, с которыми я сталкивался, заключается в том, что функция используется не так, как она определена.Если вы видите такую ошибку, вам следует убедиться, что каждая используемая вами функция правильно объявлена в каком-либо файле .h.
Вы также должны убедиться, что все соответствующие исходные файлы скомпилированы в один и тот же lib-файл.Ошибка, с которой я столкнулся, заключается в том, что у меня есть два набора файлов, скомпилированных в две отдельные библиотеки, и я выполняю перекрестный вызов между библиотеками.

Есть ли у вас на уме какая-то неудача?