Lnk1104 не удается открыть файл
Обновлено: 03.07.2024
Я создал новый проект на C ++ в Visual Studio 2008. Код еще не написан; Изменились только настройки проекта.
Когда я компилирую проект, я получаю следующую фатальную ошибку:
фатальная ошибка LNK1104: невозможно открыть файл 'C: \ Program.obj'
Эта конкретная проблема вызвана указанием зависимости для файла lib, в пути которого были пробелы. Для корректной компиляции проекта путь должен быть заключен в кавычки.
На вкладке Configuration Properties -> Linker -> Input свойств проекта есть свойство Additional Dependencies . Эта проблема была устранена путем изменения этого свойства с:
C: \ Program Files \ software sdk \ lib \ library.lib
"C: \ Program Files \ sofware sdk \ lib \ library.lib"
Где я добавил цитаты.
Боже, ты только что повесил двухдневную погоню за ошибками на 30- У меня такая же проблема. Если ваш компоновщик правильный, но каталог lib установлен неправильно, может возникнуть та же ошибка. Попробуйте заглянуть в Свойства конфигурации -> Каталоги VC ++ -> Каталоги библиотек, чтобы убедиться, что вы правильно установили библиотеку. Иногда папка lib состоит из папок x86 и x64. Вы должны установить его на один из них (в зависимости от вашего компилятора), а не на папку, содержащую оба. Не забудьте поставить точку с запятой после "C:\Program Files\sofware sdk\lib\library.lib" . Отсутствие a ; также приведет к неправильной компиляции проекта. Была эта проблема при попытке создать OpenCV с помощью Visual Studio 2005 (в Windows 8.1) . и она ее решила. Большой! Я попробовал, но у меня ничего не вышло. "Qt5Xmld.lib"; "Qt5XmlPatternsd.lib"; "Qt5Cored.lib";% (AdditionalDependencies) -Что мне изменить?Это может произойти, если файл все еще работает.
Я получаю это из-за того, что MS Security Essentials блокирует файл. да, закрыл предыдущее окно консоли, и вдруг библиотека могла быть прочитана.: -1: ошибка: LNK1104: не удается открыть файл 'debug \ ****. Exe'
Проблема исчезла для меня после закрытия и повторного открытия Visual Studio. Не уверен, почему возникла проблема, но, возможно, стоит попробовать.
Это было на VS 2013 Ultimate, Windows 8.1.
ах, Microsoft . Наша первая попытка всегда должна быть закрыта и снова открыта (или выключена и включена) - несколько загадочных ошибок исчезнут, когда мы сделаем это . Мне так стыдно, что это решение может решить мою проблему. Теперь я больше не могу выходить на улицу, чтобы встретиться с друзьями и семьей.Также убедитесь, что у вас не включено: Свойства конфигурации -> C / C ++ -> Препроцессор -> Предварительная обработка в файл .
В моем случае это тоже была проблема, но что мне делать, если я действительно хочу включить этот флаг (чтобы просмотреть файл Prepossessment)? У вас есть обходные пути: как вывести предварительно обработанный код и скомпилировать его (Visual Studio) и здесь: Компиляция проекта (VS 2008) с аргументом / p (предварительная обработка в файл) не компилируется . Но, по сути, это вариант компилятора, поэтому он подойдет либо, но не обоим сразу.У меня была такая же проблема. Она вызывалась знаком "," в имени папки дополнительного пути к библиотеке. Решалась изменением пути к дополнительной библиотеке.
Моя проблема заключалась в отсутствии .lib расширения, я просто связывал его, mylib и VS решил его найти mylib.obj .
В моем случае речь шла о неверно направленной ссылке. Project ссылался на результат другого проекта, но последний не выводил файл, в котором искал первый.
Решение 1 (для моего случая): перезапустите процесс Windows Explorer (да, файловый менеджер Windows).
- Закройте Visual Studio. Выход из Windows
- Войдите, снова откройте Visual Studio
- Стройте как обычно. Теперь он собирается и может получить доступ к проблемному файлу.
Я предполагаю, что иногда файловая система или тот, кто ее контролирует, теряются со своими разрешениями. Перед перезапуском сеанса Windows пытался убить msbuild32.exe процессы зомби , перезапустить визуальную студию, не проверять, даже показывая файл проблемы. Нет проблем с конфигурацией сборки. Это случается время от времени. Что-то внутреннее в Windows не исправляется, требуется перезагрузка.
У меня была эта проблема с VS2019 . это исправило . удивительно, что ошибки сохраняются. thxУ меня была такая же ошибка, только с пакетом Nuget, который я установил (тот, который не является только заголовком), а затем попытался удалить.
Что было неправильно для меня, так это то, что я все еще включал заголовок для пакета, который я только что удалил, в одном из моих файлов .cpp (довольно глупо, да).
Я даже удалил ссылки на дополнительные каталоги библиотеки Project -> Properties -> Linker -> General , но, конечно, безрезультатно, поскольку я все еще пытался ссылаться на несуществующий заголовок.
У меня была такая же проблема, но решения для моего случая в ответах нет. Моя антивирусная программа (AVG) определила файл MyProg.exe как вирус и поместила его в «хранилище вирусов». Вам нужно проверить это хранилище, и если файл там - то просто восстановите его. Мне это помогло.
Для проекта сборки (ProjectName -> Build Dependencies -> Build Customizations -> masm (selected)) установка параметра Generate Preprocessed Source Listing на True вызвала проблему и для меня, очистка настройки устранила ее. VS2013 здесь.
У меня та же проблема с компоновщиком, который жалуется на отсутствие основного исполняемого файла. Это произошло во время переноса нашего решения на новую Visual Studio 2013 . Решение представляет собой разнообразное сочетание управляемых и неуправляемых проектов / кода. Проблема (и решение) заключалась в отсутствии файла app.config в папке решения. Потребовался день, чтобы понять это :(, поскольку журнал вывода не очень помог.
Я отвечаю, потому что не вижу этого конкретного решения в списке других.
По-видимому, мой антивирус (Ad-Aware) отмечал DLL, от которой зависит один из моих проектов, и удалял ее. Даже после исключения каталога, в котором находится DLL, такое же поведение продолжалось до тех пор, пока я не перезагрузил свой компьютер.
В моем случае я заменил файлы математической библиотеки из предыдущего курса Game Engine Graphics на GLM. Проблема заключалась в том, что я не добавил их в проект в обозревателе решений Visual Studio (даже если они были в репозитории проекта).
Надеюсь, этот ответ поможет кому-то в нужде.
Я решил его добавление в существующий проект к моему решению , которое я забыл добавить в первый раз.
У меня была такая же ошибка:
Это было вызвано ; в конце. Если у вас несколько библиотек, их следует разделять пустым пространством (пробел), без запятой или точкой с запятой!
Так что не используйте ; или что-либо еще при перечислении библиотек в Project properties >> Configuration Properties >> Linker >> Input
Я пробовал вышеуказанное решение, но у меня не получилось. Поэтому я переименовал exe и перестроил решение. Меня устраивает.
У меня была эта точная ошибка при создании VC ++ DLL в Visual Studio 2019:
LNK1104: невозможно открыть файл 'C: \ Program.obj'
Я создал новый проект C++ в Visual Studio 2008. Код еще не написан, изменены только настройки проекта.
когда я компилирую проект, я получаю следующую фатальную ошибку:
фатальная ошибка LNK1104: не удается открыть файл 'C:Program.obj'
эта конкретная проблема вызвана указанием зависимости для файла lib, который имел пробелы в своем пути. Путь должен быть окружен кавычками для правильной компиляции проекта.
на Свойства Конфигурации -> Компоновщик -> Ввод вкладка свойств проекта, есть Дополнительные Зависимости собственность. Эта проблема была исправлена путем изменения этого свойства:
C:\Program файлы\программное обеспечение sdk\lib \ библиотека.Либ
" C:\Program файлы\программное обеспечение sdk\lib \ библиотека.lib"
где я добавил кавычки.
Это может произойти, если файл все еще работает.
:-1: ошибка: LNK1104: не удается открыть файл ' debug\****.exe'
проблема ушла для меня после закрытия и повторного открытия Visual Studio. Не знаю, почему возникла проблема, но это может быть стоит попробовать.
Это было на VS 2013 Ultimate, Windows 8.1.
проверьте также, что вы не включили это: свойства конфигурации -> C / C++ - > препроцессор -> предварительная обработка файла.
У меня было то же самое problem.It вызвано символом", " в имени папки дополнительной библиотеки path.It решается путем изменения дополнительного пути к библиотеке.
моя проблема была отсутствует .lib расширение, я просто связывал против mylib и ВС решил искать mylib.obj .
в моем случае это был вопрос неправильной ссылки. Проект ссылался на вывод другого проекта, но последний не выводил файл, где первый искал.
для сборки проекта (название проекта -> построение зависимостей -> сборки настройки -> компилятор MASM (некоторые)), задание Создать Предварительно Обработанный Список Источников до True вызвал проблему и для меня, очистив настройку, исправил ее. VS2013 здесь.
Я отвечаю, потому что я не вижу это конкретное решение, перечисленное кем-либо еще.
по-видимому, мой антивирус (Ad-Aware) отмечал DLL, от которой зависит один из моих проектов, и удалял его. Даже после исключения каталога, где живет DLL, то же самое поведение продолжалось до тех пор, пока я не перезагрузил компьютер.
Эта ошибка возникает, когда компоновщику не удается открыть файл для чтения или записи. Ниже перечислены две наиболее распространенные причины этой проблемы.
Программа уже запущена или загружена в отладчике, и
пути к библиотеке неверны или не заключены в двойные кавычки.
Существует множество других возможных причин этой ошибки. Чтобы сократить их, сначала проверьте Тип файла. Затем используйте следующие разделы для выявления и исправления конкретной проблемы.
Не удается открыть приложение или его PDB-файл
Приложение выполняется или загружается в отладчике
Если filename — имя исполняемого файла или связанный с ним PDB-файл, см. раздел Если приложение уже запущено. Затем проверьте, загружен ли он в отладчик. Чтобы устранить эту проблему, перед повторным созданием программы закройте программу и выгрузите ее из отладчика. Если приложение открыто в другой программе, например в редакторе ресурсов, закройте его. Если программа не отвечает, может потребоваться завершить процесс с помощью диспетчера задач. Также может потребоваться закрыть и перезапустить Visual Studio.
Приложение заблокировано антивирусным сканированием
Антивирусные программы часто временно блокируют доступ к вновь созданным файлам, особенно .exe и .dll исполняемые файлы. Чтобы устранить эту проблему, попробуйте исключить каталоги сборки проекта из антивирусного сканера.
Не удается открыть файл библиотеки Майкрософт
Windows библиотеки, например kernel32. lib
Если файл, который не удается открыть, является одним из стандартных файлов библиотеки, предоставляемых корпорацией Майкрософт, например kernel32. lib, может возникнуть ошибка конфигурации проекта или ошибка установки. убедитесь, что Windows SDK установлен. если для проекта требуются другие библиотеки майкрософт, такие как MFC, убедитесь, что компоненты MFC также установлены установщиком Visual Studio. Вы можете снова запустить установщик, чтобы добавить дополнительные компоненты в любое время. Дополнительные сведения см. в Изменение Visual Studio. Используйте вкладку отдельные компоненты в установщике, чтобы выбрать конкретные библиотеки и пакеты SDK.
Библиотеки vcruntime с отслеживанием версий
Библиотеки для розничной торговли, отладки или конкретной платформы
Эта ошибка может возникнуть при первой сборке для новой целевой платформы или конфигурации, например в розничной торговле или ARM64. в интегрированной среде разработки проверьте, установлены ли набор инструментов платформы и Windows SDK версии , указанной на странице свойств общие . также убедитесь, что необходимые библиотеки доступны в каталогах библиотек , указанных на странице свойств каталоги VC++. Проверьте свойства каждой конфигурации, например Debug, Retail, x86 или ARM64. Если одна сборка работает, но другая нет, Сравните параметры обоих параметров. Установите все отсутствующие необходимые инструменты и библиотеки.
Библиотека vccorlib. lib
Библиотеки в проектах из сетевых или других источников
При построении проекта, скопированного с другого компьютера, расположения установки библиотеки могут отличаться. Для сборок из командной строки убедитесь, что для сборки правильно заданы пути к переменной среды LIB и библиотеке. в Visual Studio можно просмотреть и изменить текущие пути к библиотекам, заданные на страницах свойств проекта. на странице VC++ каталоги выберите элемент управления "раскрывающийся список" для свойства каталоги библиотек , а затем нажмите кнопку изменить. В разделе вычисленное значение диалогового окна каталоги библиотек перечислены текущие пути поиска файлов библиотек. Обновите эти пути, чтобы они указывали на локальные библиотеки.
обновленные библиотеки Windows SDK
Не удается открыть сторонний файл библиотеки
Существует несколько распространенных причин этой проблемы.
Путь к файлу библиотеки может быть неверным или не заключен в двойные кавычки. Или, возможно, вы не указали его для компоновщика.
Возможно, вы установили 32-разрядную версию библиотеки, но при этом собираетесь на 64 бит или наоборот.
Библиотека может зависеть от других библиотек, которые не установлены.
Может потребоваться предоставить каталог библиотеки, переопределяющий каталог стандартной библиотеки. В командной строке используйте параметр /libpath . В интегрированной среде разработки используйте свойство Дополнительные каталоги библиотек в свойствах конфигурации > компоновщик > общую страницу свойств проекта.
Убедитесь, что установлены все версии библиотеки, необходимые для создаваемых конфигураций. воспользуйтесь программой управления пакетами vcpkg , чтобы автоматизировать установку и настройку для многих распространенных библиотек. По возможности лучше создавать собственные копии сторонних библиотек. Затем вы убедитесь, что все локальные зависимости библиотек созданы для тех же конфигураций, что и ваш проект.
Не удается открыть файл, созданный проектом
Эта ошибка может возникать, если файл filename еще не существует, когда компоновщик пытается получить к нему доступ. Это может произойти, когда один проект зависит от другого в решении, но проекты создаются в неправильном порядке. Чтобы устранить эту проблему, убедитесь, что ссылки проекта заданы в проекте, который использует этот файл. После этого отсутствующий файл будет создан до того, как он потребуется. дополнительные сведения см. в статьях добавление ссылок в проекты Visual Studio C++ и управление ссылками в проекте.
Не удается открыть файл "C: \ Program. obj"
Чтобы устранить эту проблему для сборок из командной строки, проверьте параметры параметра /libpath . Также проверьте пути, указанные в переменной среды LIB, и пути, указанные в командной строке. Обязательно используйте двойные кавычки для всех путей, содержащих пробелы.
Чтобы устранить эту проблему в интегрированной среде разработки, при необходимости добавьте двойные кавычки для следующих свойств проекта:
свойство каталоги библиотеки на странице свойства конфигурации > свойства каталоги VC++
Свойство Дополнительные каталоги библиотек на странице свойств конфигурации > компоновщик > общие
Свойство Дополнительные зависимости на странице свойств конфигурации > компоновщик > входные свойства.
Другие распространенные проблемы
Проблемы с путями или именами файлов
Параллельная синхронизация сборок
если вы используете параллельный вариант сборки, Visual Studio мог заблокировать файл в другом потоке. Чтобы устранить эту проблему, убедитесь, что один и тот же объект кода или библиотека не встроены в несколько проектов. Используйте зависимости сборки или ссылки проекта, чтобы выбрать в проекте созданные двоичные файлы.
Дополнительные зависимости, указанные в интегрированной среде разработки
При указании отдельных библиотек в свойстве Дополнительные зависимости используйте пробелы для разделения имен библиотек. Не используйте запятые или точки с запятой. При использовании пункта меню Правка для открытия диалогового окна Дополнительные зависимости используйте символы новой строки для разделения имен, а не запятых, точек с запятой или пробелов. Также используйте символы новой строки при указании путей к библиотекам в папках библиотек и дополнительных каталогах библиотек .
Слишком длинные пути
Эта ошибка может появиться, когда путь к файлу расширяется до 260 символов. При необходимости измените структуру каталогов или Сократите имена папок и файлов, чтобы сократить пути.
Слишком большие файлы
Эта ошибка может возникать из-за слишком большого размера файла. Библиотеки или объектные файлы, размер которых превышает гигабайт, может вызвать проблемы для 32-разрядного компоновщика. Возможным исправлением этой проблемы является использование 64-разрядного набора инструментов. Дополнительные сведения о том, как использовать 64-разрядный набор средств в командной строке, см. в разделе как включить 64-разрядный Visual C++ набор инструментов в командной строке. сведения о том, как использовать 64-разрядный набор инструментов в интегрированной среде разработки, см. в разделе использование MSBuild с 64-разрядным компилятором и инструментами. также см. статью Stack Overflow post: как сделать Visual Studio использовать собственную цепочки инструментов amd64.
Неправильные разрешения для файла
Эта ошибка может возникать, если у вас недостаточно разрешений для доступа к файлу filename. Это может произойти, если для доступа к файлам библиотеки в защищенных системных каталогах используется обычная учетная запись пользователя. Или, если вы используете файлы, скопированные с других пользователей, у которых все еще есть исходный набор разрешений. Чтобы устранить эту проблему, переместите файл в каталог проекта с возможностью записи. Если перемещенный файл имеет недоступные разрешения, выполните команду takeown.exe в окне командной строки администратора, чтобы стать владельцем файла.
Недостаточно места на диске
Эта ошибка может возникать, если на диске недостаточно места. Компоновщик использует временные файлы в нескольких ситуациях. Даже если на диске достаточно места, большие ссылки могут выпустить или фрагментировать свободное место на диске. Рассмотрите возможность использования параметра /OPT (оптимизация) . выполнение транзитного исключения COMDAT считывает все объектные файлы несколько раз.
Проблемы в переменной среды TMP
Если имя файла LNK nnn, то это имя файла, созданного компоновщиком для временного файла. Каталог, указанный в переменной среды TMP, может не существовать. Кроме того, для переменной среды TMP может быть задано несколько каталогов. Для переменной среды TMP должен быть указан только один путь к каталогу.
Справка, моей проблемы нет в списке!
используя Visual Studio 2010, когда я создаю + запускаю свое приложение через короткие промежутки времени, я часто получаю следующую ошибку. Если я просто подожду минуту или две и попробую еще раз, все будет хорошо. Unlocker утверждает, что дескриптор не блокирует исполняемый файл.
как я могу узнать, что блокирует его?
если это сама Visual Studio, что я должен сделать, чтобы остановить его? или альтернативно освободить файл?
была эта проблема после переустановки сегодня. Убедитесь, что служба Application Experience запущена, а не отключена. Если его установить в руководство, я считаю, что VS запустит его.
У вас, вероятно, был случайный процесс сборки, который блокировал исполняемый файл, и он (случайный процесс) не очистился. В этом случае закройте visual studio, откройте Process explorer и уничтожьте все процессы, связанные с visual studio. Затем снова откройте visual studio и попробуйте перестроить проект.
Я знаю, что это довольно старый, но у меня была такая же проблема с Visual Studio 2010, все исправлено, поэтому другие могут все еще столкнуться с этим.
добавление моего пути проекта к "исключенным элементам" в моих настройках антивируса AVG, похоже, устранило проблему для меня.
попробуйте отключить любой антивирусный / резидентный щит и посмотреть, устраняет ли он проблему. Если это так, добавьте свой путь к проекту в исключенные каталоги в конфигурации AV.
файл может быть заблокирован, потому что это сейчас запустить. Попробуйте убить процесс с помощью Диспетчера задач.
возможно, вы не закрыли выход. Закройте выходные данные, очистите и восстановите файл. Вы сможете запустить файл.
Как говорит Джонатан, - да, переименование может помочь обойти эту проблему. Но, например, я был вынужден переименовывать целевой исполняемый файл много раз, это утомительно и не хорошо.
проблема заключается в том, что при запуске проекта, а затем получить ошибку, что вы не можете построить свой проект - это так, потому что этот исполняемый файл (ваш проект) по-прежнему выполняется (вы можете проверить его через Диспетчер задач.) Если вы просто переименуете целевую сборку, через некоторое время вы получите ту же ошибку с new имя тоже, и если вы откроете диспетчер задач, вы увидите, что вы мусор системы с вашими не законченными проектами.
Visual studio для создания новой сборки необходимо удалить предыдущий исполняемый файл и создать новый вместо старого, он не может сделать это, пока исполняемый файл все еще выполняется. Итак, если вы хотите сделать новую сборку, процесс старого исполняемого файла должен быть закрыт! (странно, что visual studio не закрывает его сам по себе, и да, это похоже на какую-то багги поведение.)
это утомительно делать вручную, поэтому вы можете просто файл bat и просто щелкнуть по нему, когда у вас есть такая проблема:
это работает для меня по крайней мере. Как предположение-я не закрываю свою программу должным образом на C++, поэтому, возможно, для visual studio нормально держать ее запущенной.
дополнение: Существует большой шанс быть таким, из-за не законченного применения. Проверьте, вызывали ли вы PostQuitMessage в конец, для того, чтобы дать знать окна, что вы сделали.
Я пришел к выводу, что это какая-то ошибка Visual Studio. Возможно, C Johnson прав - возможно, процесс сборки держит файл заблокированным.
У меня есть обходной путь, который работает-каждый раз, когда это происходит - я изменяю целевое имя исполняемого файла в свойствах проекта (щелкните правой кнопкой мыши проект, затем Свойства\свойства конфигурации\общее\целевое имя).
таким образом VS создает новый исполняемый файл, и проблема обрабатывается. Каждые несколько раз я сделайте это, я возвращаюсь к исходному имени, таким образом, циклически через
Если кто-то найдет причину и решение, Пожалуйста, ответьте и я могу двигаться в ответ на ваше, как мое решение.
У меня была такая же проблема, однако с использованием Codeblocks. Из-за этой проблемы я бросил программирование, потому что каждый раз я просто хотел выбросить свой компьютер из окна.
Я хочу поблагодарить user963228, чей ответ действительно является решением этой проблемы. Вы должны поместить Application Experience в ручной запуск(вы можете сделать это, выполнив поиск служб в меню Пуск windows 7, а затем найти Application Experience и нажмите "Свойства").
эта проблема возникает, когда люди хотят tweak theyr windows 7 машина, и они решают отключить некоторые бессмысленные услуги, поэтому они google некоторые настройки руководства и большинство из этих руководств говорят, что опыт применения безопасно отключить.
Я думаю, что эта проблема должна быть связана с проблемой windows 7, а не с проблемой, и она должна быть более заметной - мне потребовалось много времени, чтобы найти это решение.
еще раз спасибо!
чтобы добавить еще одно решение в список, я обнаружил, что Visual Studio (2012 в моем случае) иногда блокирует файлы под разными процессами.
Так, на аварии, команду devenv.exe может по-прежнему работать и удерживать файл(ы). В качестве альтернативы (как я только что обнаружил), vstestrunner или vstestdiscovery также могут удерживать файл.
убейте все эти процессы, и это может решить проблему.
я запускал клиент VMWare workstation с общей папкой, определенной на виртуальной машине на всем диске C:. Когда я отключил общие папки в настройках виртуальной машины, VS2013 смог счастливо построить мой .файл EXE.
мой новый процесс есть:
1) Отключите общую папку на виртуальной машине (Настройки | Параметры | общие папки-и снимите флажок) 2) Запустите сборку на хост-ПК 3) повторно включите общую папку (и продолжайте оттуда)
надеюсь, это может помочь кому-то еще.
(кстати, ошибки, которые вы получаете, это .exe (или другие файлы) заблокированы или требуют разрешения администратора, но это отвлекающий маневр - мне кажется, что общий ресурс VMWare вызывает эти файлы отображаются как заблокированные.)
ошибка возникает (по крайней мере, иногда) из слишком длинных путей. В моем проекте просто сокращение пути к выходному файлу делает работу: "Свойства / Свойства Конфигурации / Общий / Промежуточный Каталог"
кажется, что я попал в ограничение пути 250 символов.
работая с принципами программирования и практикой Bjarne Stroustrup, используя пример c++ "FLTK", я получил ту же ошибку, но через 1 час у меня появилась идея, я отслеживал одну из библиотек, уже виденных в свойствах проекта -> Компоновщик -> ввод -> дополнительные зависимости, в моем случае я отслеживал kernel32.lib, чтобы увидеть, где был расположен и увидел, что было много kernel32.Либ в разных папках. Поэтому я начал копировать библиотеки FLTK в эти папки, и последний, который я пробовал, работал. Visual Studio 2013 Экспресс нашел флткд.Либ и код сработали.
в моем случае правильный маршрут был C:\Program файлы (x86)\Windows Kits\8.1\Lib\winv6.3 \ um\x86
Я не знаю, как установить этот маршрут внутри Visual Studio.
надеюсь, что это поможет вам люди.
У меня была та же проблема. Со мной exe все еще работал, но я не мог закончить его с помощью Диспетчера задач. Просто перезапустив VS, это сработало для меня.
мой заключается в том, что если вы установите опцию MASM listing file некоторый дополнительный выбор, это даст вам эту ошибку.
но любой дополнительный у вас есть проблема.
обычно это означает, что ваша программа заблокирована и не может быть убита через Диспетчер задач или Process explorer. Я встретил аналогичный случай, что моя программа имела исключение во время работы и вызвала отчет об ошибках windows, который заблокировал программу. в случае, если Windows Error reporting блокирует программу, вы можете перейти в Панель управления - >Система и безопасность->Центр действий->настройки отчетов о проблемах, чтобы установить "никогда не проверять решения". надеюсь, что это помогает.
У меня проблемы с компиляцией базовой программы openGL на VS 2012. Я получаю ошибку сборки после компиляции, давая мне:
Я следовал инструкциям, данным мне в документации для GLEW.
Я также добавил glew32.dll в папку Debug в папке проекта вместе с исполняемым файлом. Пока я продолжаю получать эту ошибку.
Если вам нужно более подробное разъяснение шагов, которые я сделал, пожалуйста, не стесняйтесь спрашивать
Решение
Честно говоря, нет реальной пользы от использования 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
Другие решения
Это случилось со мной в этой ситуации, я очищаю решение и собираю его снова, затем возникает много ошибок, таких как LNK1104.
После попытки перезапустить IIS я успешно строю решение без ошибок LNK1104. Я не знаю почему, но перезапуск IIS занимает гораздо больше времени, чем обычно, поэтому я предполагаю, что что-то используется другим рабочим процессом IIS.
Просто сделайте снимок, чтобы увидеть, происходит ли эта магия на вас.
Шаги по использованию классов из другого проекта (добавление ошибок компоновщика заголовка и решателя)
«Свойства> Linker> Дополнительные каталоги библиотеки». Укажите местоположение создаваемого файла lib.
«Свойства> Линкер> Ввод> Дополнительные зависимости»: Добавьте имя файла lib.
Это похоже на то, что библиотека была указана как зависимость, но компоновщик / дополнительные пути поиска не были установлены для включения каталога, в котором расположена библиотека.
Этот вопрос старый и помечен как решенный, но у меня были похожие симптомы проблемы с совершенно другим решением. Так что на случай, если кто-то еще споткнется здесь:
Оказалось, что, поскольку у меня было 2 проекта под одним решением (dll и exe), порядок построения был смешанным (из окна вывода):
Читайте также: