Visual studio 2010 express + win sdk = не может открыть входной файл 'kernel32.lib'

Я использовал для компиляции для x64, используя VS2008 express и win SDK. Недавно была перестроена моя машина (обновлена до 64-битной Windows 7) и получила последнюю экспресс-установку. Следуйте той же процедуре, чтобы разрешить x64-цели, а мои источники больше не ссылаются. независимо от того, что я делаю, я всегда получаю:

LINK: фатальная ошибка LNK1181: невозможно открыть входной файл 'kernel32.lib'

достаточно забавная 32-битная компиляция отлично работает.

Это какая-то хорошо известная проблема? Google не дал мне никаких подсказок, как справиться с этим лишь несколькими упоминаниями одной и той же проблемы, но никаких решений.

Можно ли использовать VS 2010 с win 7 SDK для целевого 64-битного?

спасибо Pawel

Ответ 1

решение было мертвым легко в конце. Хитрость заключается в том, чтобы указать VS, чтобы выиграть SDK, который по какой-то причине был неправильным в моем случае. Project Properties -> VC++ Directories -> Library Directories должен указывать на C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64

Ответ 2

Что-то еще, что я обнаружил, также очень легко, - перейти в Project Properties- > General и установить Platform Toolset в Windows7.1SDK. Интересно, почему это работает...

Ответ 3

У меня была такая же проблема, и ответы здесь помогли мне, но мне пришлось делать больше.

Что-то испортило мою установку Windows SDK, поэтому мне не хватало всех .lib файлов, которые входят в C:\Program Files\Microsoft SDK\Windows\v7.1\Lib\(внутри папки x64 было нормально). Поэтому я последовал за тем, что было сказано здесь, и переустановил его. Чем я могу установить Platform Toolset для Windows7.1SDK (как в VS2010, так и VS2013).

Это работает, потому что Platform Toolset изменяет путь $(WindowsSdkDir) в Visual Studio (эти пути сохранены в системном реестре), которые были повреждены, если Kernel32.lib не найден.

Ответ 4

Если ни одно из вышеперечисленных решений не работает. Остановитесь и сделайте проверку здравомыслия. Я сгорел, используя неправильную строку конфигурации -G, и это дало мне эту вводящую в заблуждение ошибку.

Сначала запустите из командной строки VS not обычную командную строку. Вы можете найти его в Start Menu -> Visual Studio 2015 -> MSBuild Command Prompt for VS2015

Это устанавливает все правильные пути к инструментам VS и т.д.

Теперь посмотрим, какие генераторы доступны из cmake...

cmake -help

...<snip>... The following generators are available on this platform: Visual Studio 15 [arch] = Generates Visual Studio 15 project files. Optional [arch] can be "Win64" or "ARM". Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files. Optional [arch] can be "Win64" or "ARM". Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files. Optional [arch] can be "Win64" or "ARM". Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files. Optional [arch] can be "Win64" or "ARM". Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files. Optional [arch] can be "Win64" or "IA64". ...

Затем выберите соответствующую строку с добавленной дугой.

mkdir _build cd _build cmake .. -G "Visual Studio 15 Win64"

Запуск cmake в подкаталоге упрощает выполнение "чистой", поскольку вы можете просто удалить все в этом каталоге.

Я обновился до Visual Studio 15, но не обращал внимания и пытался сгенерировать в 2012 году.

Ответ 5

FWIW, у меня была та же проблема с Visual Studio 2013, когда вся установка v8.1 SDK (файлы + reg-ключи) прошла AWOL, вероятно, вызвана установкой Emborlandero RAD Studio.

Установка переменной среды WindowsSdkDir не имела никакого эффекта, поскольку сама Studio (devenv.exe, среда, проверенная через Process Explorer) и командный файл, вызванный из пакетного файла, вызванного из vcvarsall.bat, эффективно удалил эту переменную, потому что они не могли " t найдите SDK v8.1.

Visual Studio не позволяет настраивать каталоги конкретных машин на машинной основе (предложение о включении этой зависимости в каждый файл проекта смехотворно без веры) и переустановке SDK v8.1 было невозможно своевременно. Быстрое исправление, чтобы заставить Studio работать снова в то же время, заключалось в том, чтобы добавить строковое значение InstallationFolder под

Software/Microsoft/Microsoft SDKs/Windows/v8.1/

с тем же содержимым, что и кузена v8.0. Это значение находилось в HKLM/Wow6432Node, но должно выполняться обычное HKLM или HKCU.

Это привело к немедленной работе Studio без перезагрузки.