visual studio 2010 express + win sdk = impossible d'ouvrir le fichier d'entrée 'kernel32.lib'
J'avais l'habitude de compiler pour x64 à l'aide de VS2008 express et de gagner du SDK. Récemment reconstruit ma machine (mise à niveau vers Windows 7 64 bits) et le dernier courrier express installé. J'ai suivi la même procédure pour autoriser les cibles x64 et mes sources ne sont plus liées. Peu importe ce que je fais, je reçois toujours:
LINK: erreur irrécupérable LNK1181: impossible d'ouvrir le fichier d'entrée 'kernel32.lib'
la compilation 32bit assez drôle fonctionne bien.
Est-ce un problème bien connu? Google ne m'a pas donné d'indications sur la manière de résoudre le problème, juste quelques mentions du même problème mais pas de solutions.
Est-il possible d'utiliser VS 2010 avec win 7 SDK pour cibler 64 bits?
merci Pawel
la solution était facile à la fin. L'astuce consiste à indiquer à VS de gagner un SDK qui, pour une raison quelconque, était inexact dans mon cas. Project Properties -> VC++ Directories -> Library Directories doit pointer sur C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64
Une autre chose que j'ai trouvée, également très simple, consiste à aller dans Propriétés du projet -> Général et à définir Platform Toolset sur Windows7.1SDK. Je me demande pourquoi cela fonctionne ...
J'ai eu le même problème et les réponses ici m'ont aidé, mais je devais faire plus de choses.
Quelque chose avait corrompu mon installation du SDK Windows. Il me manquait donc tous les fichiers .lib qui se trouvaient dans C:\Program Files\Microsoft SDK\Windows\v7.1\Lib\(le dossier x64 à l'intérieur était ok). J'ai donc suivi ce qui a été dit ici et l'ai réinstallé. Que je puisse définir Platform Toolset sur Windows7.1SDK (dans VS2010 et VS2013).
Cela fonctionne car Platform Toolset modifie le chemin $ (WindowsSdkDir) dans Visual Studio (ces chemins enregistrés se trouvent dans le registre du système), qui ont été cassés si Kernel32.lib n'était pas trouvé.
Si aucune des solutions ci-dessus ne fonctionne. Arrêtez-vous et faites un bilan de santé. Je me suis brûlé en utilisant la chaîne de configuration -G incorrecte et cela m'a donné cette erreur trompeuse.
Commencez par exécuter à partir de l'invite de commande VS not l'invite de commande standard. Vous pouvez le trouver dans Start Menu -> Visual Studio 2015 -> MSBuild Command Prompt for VS2015
Ceci configure tous les chemins corrects vers les outils VS, etc.
Maintenant, voyez quels générateurs sont disponibles chez 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".
...
Ensuite, choisissez la chaîne appropriée avec l'arch ajouté.
mkdir _build
cd _build
cmake .. -G "Visual Studio 15 Win64"
L'exécution de cmake dans un sous-répertoire facilite la tâche de "nettoyage", car vous pouvez simplement supprimer tout ce qui se trouve dans ce répertoire.
Je suis passé à Visual Studio 15, mais je ne faisais pas attention et je tentais de générer pour 2012.
FWIW, j’ai eu le même problème avec Visual Studio 2013 lorsque l’ensemble de l’installation du SDK v8.1 (fichiers + clés de registre) a été annulé, probablement à cause de l’installation de Emborlandero RAD Studio.
La définition de la variable d'environnement WindowsSdkDir n'a aucun effet puisque Studio lui-même (devenv.exe, environnement inspecté via Process Explorer) et un fichier de commandes appelé à partir d'un fichier de commandes appelé à partir de vcvarsall.bat ont effectivement supprimé cette variable car ils ne trouvaient pas le SDK v8.1.
Visual Studio n'autorise pas la configuration des répertoires spécifiques à une machine d'une manière globale (la suggestion d'insérer cette dépendance de la machine dans chaque fichier de projet est ridicule) et réinstaller le SDK v8.1 n'était pas possible. en temps opportun. Une solution rapide pour que Studio fonctionne à nouveau dans l'intervalle consistait à ajouter la valeur de chaîne InstallationFolder sous
Software/Microsoft/Microsoft SDKs/Windows/v8.1/
avec le même contenu que son cousin v8.0. C'était sous HKLM/Wow6432Node mais HKLM ou HKCU devrait également fonctionner.
Cela a permis à Studio de fonctionner à nouveau immédiatement, sans même un redémarrage.