Процесс перехода от исходного кода к исполняемому файлу обычно состоит из двух этапов для C и связанных с ним языков, хотя IDE, вероятно, представляет его как единый процесс.

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

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

2/Связывание, следующий этап, объединяет все ваши объектные файлы с библиотеками для создания исполняемого файла. Я не буду здесь рассматривать динамическую компоновку, так как это усложнит объяснение и принесет мало пользы.

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

В качестве примера рассмотрим следующий упрощенный код C (xx.c) и команду.

#include <bob.h>
int x = bob_fn(7);

cc -c -o xx.obj xx.c

Это компилирует файл xx.c в xx.obj. bob.h содержит прототип для bob_fn(), так что компиляция пройдет успешно. -c указывает компилятору генерировать объектный файл, а не исполняемый файл, а -o xx.obj задает имя выходного файла.

Но фактический код для bob_fn() находится не в заголовочном файле, а в /bob/libs/libbob.so, поэтому для ссылки вам нужно что-то вроде:

cc -o xx.exe xx.obj -L/bob/libs;/usr/lib -lbob

Это создает xx.exe из xx.obj, используя библиотеки (искомые по заданным путям) формы libbob.so (обычно lib и .so добавляются компоновщиком). В этом примере -L задает путь поиска библиотек. -l указывает библиотеку, которую нужно найти для включения в исполняемый файл, если это необходимо. Компоновщик обычно берет "bob" и находит первый соответствующий файл библиотеки в пути поиска, указанном -L.

Файл библиотеки на самом деле является набором объектных файлов (подобно тому, как zip-файл содержит несколько других файлов, но не обязательно сжатых). в исполняемый файл, как и ваш файл xx.obj. Обычно это продолжается до тех пор, пока не останется неразрешенных внешних факторов. «Соответствующая» библиотека — это модификация текста «bob», она может искать libbob.a, libbob.dll, libbob.so, bob.a, bob.dll, bob.so и так далее. Релевантность определяется самим компоновщиком и должна быть задокументирована.

Как это работает, зависит от компоновщика, но в основном это все.

1/Все ваши объектные файлы содержат список неразрешенных внешних объектов, которые им необходимо разрешить. Компоновщик объединяет все эти объекты и фиксирует связи между ними (разрешает как можно больше внешних).

2/ Затем для каждого внешнего все еще неразрешенного компоновщик просматривает файлы библиотеки в поисках объектного файла, который может удовлетворить ссылку. Если он находит его, он втягивает его — это может привести к дальнейшим неразрешенным внешним факторам, поскольку втягиваемый объект может иметь свой собственный список внешних факторов, которые необходимо удовлетворить.

3/Повторяйте шаг 2 до тех пор, пока не останется неразрешенных внешних или не будет возможности разрешить их из списка библиотек (это то, где была ваша разработка, поскольку вы не включили файл библиотеки LUA).

Усложнение, о котором я упоминал ранее, — это динамическое связывание. Здесь вы связываетесь с заглушкой процедуры (своего рода маркером), а не с фактической процедурой, которая позже разрешается во время загрузки (когда вы запускаете исполняемый файл). Такие вещи, как общие элементы управления Windows, находятся в этих библиотеках DLL, поэтому их можно изменять без повторной компоновки объектов в новый исполняемый файл.

Шаг 1 - Компилятор:

• Вход: файл [ы] исходного кода
• Процесс: Анализ исходного кода и перевод в машинный код
• Output: Object file[s], which consist[s] of:
  • The names of symbols which are defined in this object, and which this object file "exports"
  • Машинный код, связанный с каждым символом, определенным в этом объектном файле.
  • Имена символов, которые не определены в этом объектном файле, но от которых зависит программное обеспечение в этом объектном файле и с которыми оно впоследствии должно быть связано, т.е. имена, которые этот объектный файл «импортирует»

Шаг 2 - Связывание:

• Input:
  • Object file[s] from step 1
  • Библиотеки других объектов (например, из ОС и другого программного обеспечения)
• Process:
  • For each object that you want to link
  • Получить список символов, которые импортирует этот объект
  • Найдите эти символы в других библиотеках
  • Свяжите соответствующие библиотеки с вашими объектными файлами
• Выход: один исполняемый файл, который включает в себя машинный код всех ваших объектов, а также объекты из библиотек, которые были импортированы (связаны) с вашими объектами.

Два основных шага — это компиляция и компоновка.

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

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

Теперь, чтобы объяснить кое-что о «внешнем «C», вам нужно:

C не имеет перегрузки функций. Функция всегда узнаваема по имени. Поэтому, когда вы компилируете код как код C, в объектном файле сохраняется только настоящее имя функции.

С++, однако, имеет то, что называется "перегрузка функций/методов". Это означает, что имени функции уже недостаточно для ее идентификации. Поэтому компиляторы C++ создают "имена" для функций, которые включают прототипы функции (поскольку имя плюс прототип однозначно идентифицируют функцию). Это известно как «искажение имени».

Спецификация «extern «C»» необходима, когда вы хотите использовать библиотеку, которая была скомпилирована как код «C» (например, предварительно скомпилированные двоичные файлы Lua) из проекта C++.

Для вашей точной проблемы: если это все еще не работает, эти подсказки могут помочь: * были ли двоичные файлы Lua скомпилированы с той же версией VC++? * можете ли вы просто скомпилировать Lua самостоятельно, либо в своем решении VC, либо как отдельный проект в виде кода C++? * Вы уверены, что правильно написали все "внешние "C""?

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

Причина, по которой вы получаете «неразрешенные внешние символы», заключается в том, что компиляция в С++ работает в два этапа. Сначала код компилируется, каждый файл .cpp в своем собственном файле .obj, затем запускается «компоновщик» и объединяет все эти файлы .obj в файл .exe. Файл .lib — это просто набор файлов .obj, объединенных вместе, чтобы немного упростить распространение библиотек. Таким образом, добавляя все "#include" и объявление extern, вы сообщаете компилятору, что где-то можно найти код с этими сигнатурами, но компоновщик не может найти этот код, потому что он не знает, где находятся эти файлы .lib с фактическим кодом. размещен.

Убедитесь, что вы прочитали REDME библиотеки, обычно там есть довольно подробное объяснение того, что вам нужно было сделать, чтобы включить ее в свой код.

Вы также можете ознакомиться с этим: КОМПИЛЕР, АССЕМБЛЕР, ЛИНКЕР И ЗАГРУЗЧИК: КРАТКАЯ ИСТОРИЯ .