Visual Studio 2012 - ошибка LNK1104: невозможно открыть файл 'glew32.lib'

У меня возникают проблемы с компиляцией базовой программы openGL на VS 2012. Я получаю ошибку сборки при компиляции, предоставляя мне:

1>LINK : fatal error LNK1104: cannot open file 'glew32.lib'

Я следил за инструкциями, предоставленными мне документацией для GLEW.

В проекте OpenGL откройте Project → Properties → Свойства конфигурации → Linker → Input → Additional Dependencies → add glew32.lib.

Также вы должны включить #include в свои источники; Для этого добавьте путь к вашей папке glew: Project → Свойства → Свойства конфигурации → Общие → Каталоги VС++ → Включить каталоги и библиотечные каталоги;

C/С++ Tab → Общие → Дополнительные каталоги Include - Добавить папку lib там

Я также добавил glew32.dll в папку "Отладка" в папке проекта вместе с исполняемым файлом. До сих пор я продолжаю получать эту ошибку.

Если вам нужно более подробное разъяснение шагов, которые я сделал, не стесняйтесь спрашивать

Ответ 1

Честно говоря, нет никакой реальной пользы от использования DLL-версии glew (за исключением уменьшенного размера исполняемого файла, но это не имеет большого значения для современных ПК с ОС Windows).

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

Статическая библиотека связывания также более переносима в Windows, она будет работать с MSVC и MinGW (тогда как библиотека DLL работает только с MSVC). Ссылка на glew32s и поместите это в любой каталог, который вы решили использовать для дополнительных зависимостей в библиотеке.

Вот пример конфигурации решения для проекта, который я написал, который использует glew. Я установил соглашение для этого конкретного программного обеспечения, где зависимости времени компиляции хранятся в platform/<Subsystem> . Таким образом, у меня есть glew32s.lib (32-разрядный) и glew64s.lib (64-разрядный) в ./Epsilon/platform/OpenGL/glew {32 | 64} s.lib

Ответ 2

Это случилось со мной в этой ситуации, я очищаю решение и строю его снова, затем происходит много ошибок, таких как LNK1104.

После попытки перезапуска IIS я успешно создаю решение без ошибок LNK1104. Я не знаю, почему, но перезапуск IIS занимает гораздо больше времени, чем обычно, поэтому я предполагаю, что что-то используется другим рабочим процессом IIS.

Просто дайте шанс увидеть, если эта магия случится на вас.

Ответ 3

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

Это может помочь.

Ответ 4

Шаги по использованию классов образуют другой проект (добавьте ошибки компоновщика заголовка и решателя)

Чтобы добавить заголовок из другого проекта, сначала перейдите в "Свойствa > С++ > Общие > Дополнительные каталоги Include" и добавьте каталог, содержащий заголовок. Теперь вы сможете добавить заголовок класса из другого проекта, но запуск проекта по-прежнему вызовет ошибки компоновщика.
Добавьте __ declspec (dllexport) перед классом, который вы используете для другого проекта. Это можно добавить в заголовочный файл этого класса. Это должно быть добавлено непосредственно перед функцией или переменной или именем класса. Теперь вы получите файл lib. (если помещено в неправильное место, вы можете получить это предупреждение: https://msdn.microsoft.com/en-us/library/eehkcz60.aspx)
"Свойствa > Коннектоp > Дополнительные каталоги библиотек". Укажите местоположение созданного файла lib.
"Свойствa > Линкерa > Ввод > Дополнительные зависимости": добавьте имя файла lib.

Ответ 5

Этот вопрос старый и отмеченный решен, но у меня были аналогичные проблемы с совершенно другим решением. Так что на всякий случай кто-то натыкается сюда:
Оказалось, что из-за того, что у меня было 2 проекта под одним решением (dll и exe), заказ здания был смешанным (из выходного окна):

1> Rebuilding project1..
2> Rebuilding project1..
1> file1.cpp
2> file1.cpp

и т.д. По сообщению, которое вы скопировали, кажется, что у вас тоже есть несколько проектов под одним решением. Один проект искал файл *.lib, который еще не был создан другой сборкой.
Решение:
Щелкните правой кнопкой мыши на главном проекте → Build Dependencies → Project Dependencies.. → Отметьте, от какого проекта зависит основное.