Comment faire en sorte que Visual Studio utilise la chaîne d'outils AMD64 native
Comment faire en sorte que Visual Studio 2012 utilise la chaîne d'outils AMD64 native plutôt que le compilateur croisé x86_AMD64 par défaut?
Je suis en train de construire une grande bibliothèque qui entraîne un manque de mémoire de la part de l'éditeur de liens lors de l'optimisation du programme entier et de la génération de code de liaison.
J'ai trouvé deux anciens messages ( ici et ici ) posant la même question, mais pas encore de réponse. Microsoft fournit de la documentation sur la manière de spécifier la chaîne d’outils sur la ligne de commande , mais pas dans l’EDI.
Vous devez définir la variable d'environnement "_IsNativeEnvironment" sur "true" avant de démarrer Visual Studio 2012 IDE:
set _IsNativeEnvironment=true
start "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" your_solution.sln
Pour Visual Studio 2013, le nom de la variable d'environnement est différent:
set PreferredToolArchitecture=x64
sbm start "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" your_solution.sln
Attention, cette technique ne fonctionne pas si la version de IDE ne correspond pas à la version de la chaîne d’outils. Autrement dit, si vous utilisez VS2013 IDE configuré pour exécuter le compilateur VS2012, vous n'avez aucune chance. Mais une telle combinaison est rare.
Voici quelques liens pour plus d'informations:
comment intégrer PreferredToolArchitecture au projet dans VS13
Il existe une autre méthode pour forcer l'utilisation de l'éditeur de liens 64 bits projet par projet pour Visual Studio 2013. Modifiez votre fichier .vcxproj et insérez ce qui suit après la ligne <Import...Microsoft.Cpp.Defaults:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup>
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
</PropertyGroup>
Si votre objectif est d’utiliser l’environnement native plutôt que spécifiquement AMD64_x86, vous pouvez définir la propriété UseNativeEnvironment dans votre fichier de projet:
<PropertyGroup>
<UseNativeEnvironment>true</UseNativeEnvironment>
</PropertyGroup>
(Je l'ai ajouté avec succès au PropertyGroup "Globals".)
Vous pouvez vérifier quelle chaîne d'outils est utilisée en ajoutant l'option du compilateur /Bv. Exemple de sortie est ci-dessous. Notez que le répertoire de la boîte à outils apparaît après bin\ (AMD64_x86 dans ce cas).
2>ClCompile:
2> Compiler Passes:
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\CL.exe: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\c1.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\c1xx.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\c2.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\link.exe: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64\mspdb120.dll: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64_x86\1033\clui.dll: Version 18.00.31101.0
Je sais que cette publication est plutôt ancienne, mais elle reste pertinente pour VS 2017. Vous avez également la variable d'environnement "PreferredToolArchitecture" et un paramètre "intégré" dans IDE n'est pas facilement disponible.
Cependant, vous pouvez facilement intégrer cela sur une base de projets en projets afin de pouvoir toujours choisir l’architecture des outils à utiliser. Peut-être que cela est utile pour certains. Faire ceci:
- Accédez au gestionnaire de propriétés et créez une nouvelle feuille de propriétés, e. g. nommé "x64 Toolchain.props" afin que vous sachiez ce qu'il fait. Avec une feuille de propriétés distincte, vous pouvez alors basculer l'architecture de l'outil selon les besoins en incluant ou non la feuille dans un projet.
- Ouvrez les propriétés de cette nouvelle feuille, accédez à "Propriétés communes\Macros utilisateur" et cliquez sur "Ajouter une macro".
- Dans la boîte de dialogue, vous définissez le nom sur "PreferredToolArchitecture", la valeur sur "x64" et cochez la case "Définir cette macro en tant que variable d'environnement dans l'environnement de construction".
- Vous pouvez également accéder à "Propriétés communes\C/C++\Ligne de commande" et ajouter "/ Bv" sous "Options supplémentaires". Cela permettra au compilateur de produire les outils qu’il utilise, y compris son chemin et son numéro de version, ce qui peut être utile pour vérifier si l’architecture souhaitée est réellement utilisée. Il placera les entrées dans la fenêtre de sortie du journal comme suit:
Passe du compilateur:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1.dll: version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1xx.dll: Version 19.15.26730.0
C:\Fichiers de programme (x86)\Microsoft Visual Studio\2017\Entreprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c2.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\link.exe: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\mspdb140.dll: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\1033\clui.dll: Version 19.15.26730.0 - Désormais, pour tous les projets devant être générés avec l'architecture d'outil x64, incluez la nouvelle feuille de propriétés dans le projet dans le gestionnaire de propriétés. Et pour ceux qui ne devraient tout simplement pas l'inclure. C'est tout.
HTH
J'ai un problème similaire lors de l'utilisation de Visual Studio 2010 sur XP 64 SP2. Si je mets le répertoire exécutable VC++ sur le bac AMD64 (le dossier x64 natif) en tant que premier du chemin de recherche, le message d'erreur TRK0002… valeur de descripteur non valide apparaît.
Mais si je définis _IsNativeEnvironment = true dans une invite de commande Visual Studio 2010 et que je lance l'ide à partir de la ligne de commande telle que publiée précédemment, l'erreur disparaîtra. Apparemment, l'environnement IDE de l'interface graphique 32 bits reçoit des informations d'un processus 64 bits et attend des informations d'un processus 32 bits tel que x86\cl.exe ou x86_64\cl.exe.
Dans un scénario où vous souhaitez compiler un exécutable IA64 bits et utilisez le compilateur x86_ia64\cl.exe. Etant donné que vous utilisez un compilateur croisé 32 bits et que la variable _IsNativeEnvironment est définie sur true, ceci doit perturber le IDE lors de la publication de messages dans ses consoles de fenêtre. Définissez _IsNativeEnvironment = false si vous l'avez précédemment définie sur true.
Le IDE devrait indiquer qu'un compilateur natif était utilisé sur une machine 64 bits native et devrait avoir automatiquement défini cette variable sur la valeur appropriée lorsque le compilateur natif a été sélectionné dans l'EDI. Un correctif simple n'a jamais été appliqué pour corriger ce problème. Solution. Faites-le vous-même à partir de l'invite ou achetez le dernier IDE de Microsoft pour résoudre le problème.
Les vrais assistants de Microsoft sont donc les développeurs qui travaillent principalement à partir de la ligne de commande. Et les autres développeurs, qui portent les chapeaux pointus et sont assis dans un coin, ont probablement été embauchés chez Apple et étaient plus préoccupés par l'apparence que par la fonction.
Le but d'un IDE est de simplifier le codage en utilisant un éditeur de texte et un Makefile à partir de la ligne de commande.