Visual Studio 2012-ошибка LNK1104: не удается открыть файл ' glew32.Либ'
У меня возникли проблемы с компиляцией базовой программы openGL на VS 2012. Я получаю ошибку построения на compiltation дает мне:
1>LINK : fatal error LNK1104: cannot open file 'glew32.lib'
я следовал инструкциям, данным мне документацией для GLEW.
в вашем проекте OpenGL откройте проект - > свойства - > свойства конфигурации - > Компоновщик - > ввод - > дополнительные зависимости - > добавить glew32.движение за освобождение.
также вы должны включить #include в свои источники; для этого добавьте путь к вашему glew папка: проект - > свойства - > свойства конфигурации - > общие - > каталоги VC++ - > включить каталоги и каталоги библиотеки;
вкладка C/C++ - > общие - > дополнительные каталоги включения-Добавить папку lib там
Я также добавил glew32.dll в мою папку отладки в моей папке проекта вместе с исполняемым файлом. До сих пор я продолжаю получать эту ошибку.
Если вам нужно больше дальнейшего разъяснения шагов, которые я сделал пожалуйста, не стесняйтесь спрашивать
5 ответов
честно говоря, нет никакой реальной выгоды от использования DLL-версии glew (за исключением уменьшенного размера исполняемого файла, но это вряд ли имеет значение на современных ПК с Windows).
это не так, как вы можете просто бросить новую версию DLL в приложение и использовать расширения, которые вы никогда не использовали раньше. Аналогично, исправления ошибок настолько нечасты / ненужны с библиотекой, которая в основном просто анализирует спецификацию расширения. файлы, которые используют DLL как средство исправления ошибок загрузки расширений в поставляемое программное обеспечение также не практично. Статически связываясь с glew (это означает glew32s.lib
) имеет гораздо больше смысла в долгосрочной перспективе.
статическая библиотека ссылок также более переносима в Windows, она будет работать с MSVC и MinGW (в то время как библиотека DLL работает только с MSVC). Ссылка против glew32s
и поместите это в любой каталог, который вы решили использовать для дополнительных зависимостей библиотеки.
Вот пример конфигурации решения для проекта, который я написал, который использует glew. Я установили Соглашение для этого конкретного программного обеспечения, где зависимости времени компиляции хранятся в
platform/<Subsystem>
. Таким образом, у меня glew32s.lib
(32-bit) и glew64s.lib
(64-бит)./Эпсилон/платформа/версия OpenGL/библиотеки GLEW{32/64}С. Либ
Это случилось со мной в этой ситуации, я очищаю решение и строю его снова, тогда возникает много ошибок, таких как LNK1104.
после попытки перезапуска IIS я успешно создаю решение без ошибок LNK1104. Я не знаю, почему, но перезапуск IIS занимает гораздо больше времени, чем обычно, поэтому я предполагаю, что что-то используется другим рабочим процессом IIS.
просто дайте шанс, чтобы увидеть, если эта магия происходит на вас.
шаги по использованию классов образуют другой проект (добавить ошибки компоновщика заголовка и решателя)
чтобы добавить заголовок из другого проекта, сначала перейдите в "свойства > c++ > общие > дополнительные каталоги Include" и добавьте каталог, содержащий заголовок. Теперь вы сможете добавить заголовок класса из другого проекта, но проект все-таки вызвать ошибки компоновщика.
добавить _ _ declspec (dllexport) до начала занятий вы используете для другого проекта. Это можно добавить в файл заголовка этого класса. Это должно быть добавлено непосредственно перед именем функции, переменной или класса. Теперь вы получите файл lib. (если расположен в неправильном месте, вы можете получить это предупреждение: https://msdn.microsoft.com/en-us/library/eehkcz60.aspx)
"Свойства - > Компоновщик - > Дополнительные Каталоги Библиотек". Укажите расположение генерируемого файла lib.
"Свойства" > "Компоновщик > Ввод > Дополнительные Зависимости" добавить имя файла lib.
Это похоже на то, что библиотека была указана как зависимость, но путь компоновщика/дополнительного поиска не был установлен для включения каталога, в котором находится библиотека.
этот вопрос старый и отмеченный решен, но у меня были аналогичные симптомы проблемы с совершенно другим решением. Так что на всякий случай, если кто-то еще споткнется здесь:
Оказалось, что, поскольку у меня было 2 проекта под одним решением (dll и exe), порядок построения был смешанным (из окна вывода):
1> Rebuilding project1..
2> Rebuilding project1..
1> file1.cpp
2> file1.cpp
и так далее. По скопированному сообщению, похоже, у вас тоже есть несколько проектов под одним решением. Один проект искал *.файл lib, что другая сборка еще не создана.
Решение:
Щелкните правой кнопкой мыши на" main " project - > Build Dependencies - > Project Dependencies.. - >Отметьте, от какого проекта зависит основной.