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}С. Либ

enter image description here


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

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

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


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

  1. чтобы добавить заголовок из другого проекта, сначала перейдите в "свойства > c++ > общие > дополнительные каталоги Include" и добавьте каталог, содержащий заголовок. Теперь вы сможете добавить заголовок класса из другого проекта, но проект все-таки вызвать ошибки компоновщика.

  2. добавить _ _ declspec (dllexport) до начала занятий вы используете для другого проекта. Это можно добавить в файл заголовка этого класса. Это должно быть добавлено непосредственно перед именем функции, переменной или класса. Теперь вы получите файл lib. (если расположен в неправильном месте, вы можете получить это предупреждение: https://msdn.microsoft.com/en-us/library/eehkcz60.aspx)

  3. "Свойства - > Компоновщик - > Дополнительные Каталоги Библиотек". Укажите расположение генерируемого файла lib.

  4. "Свойства" > "Компоновщик > Ввод > Дополнительные Зависимости" добавить имя файла lib.


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

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


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

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

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