Eclipse ne pas reconnaître les types de stdint.h pour les BRAS Windows de GCC de la chaîne d'
J'ai Eclipse Juno pour les développeurs C/C++ installé avec GNU BRAS Développement C/C++ en charge les plug-in à partir de http://sourceforge.net/projects/gnuarmeclipse.
Dans mon projet, je suis à l'aide des types comme uint_32t
, int16_t
et uint8_t
que vient normalement à partir de stdint.h
. Alors que j'ai forcé l'Éclipse pour voir les en-têtes standard de mon compilateur en pointant directement le répertoire où le include
répertoire des mensonges, des types mentionnés ne sont pas résolus. Cela me donne beaucoup de marques rouges sur les symboles non résolus et faire un peu de problèmes avec le code d'achèvement des fonctions déclarées avec ces types.
Le même problème avec la norme définitions de macro comme GNUC - normalement CDT voir ces C de GNU, ou GNU C++, mais avec l'ensemble des outils mis à BRAS Windows de GCC, il ne l'est pas. Étrange.
Que puis-je faire pour résoudre ce et retour le principal boost Eclipse donne de la productivité?
OriginalL'auteur Manveru | 2012-07-26
Vous devez vous connecter pour publier un commentaire.
Je pense que j'ai trouvé la solution à mon problème. Le problème était le CDT GCC Builtin les Paramètres du Compilateur fournisseur, qui a essayé de lancer le
gcc
au lieu dearm-elf-gcc
. J'ai ajouté un préfixe pour le domaineCommand to get compiler specs:
1 à invoquer le compilateur par son nom propre.Et voilà, tous les symboles non résolus disparu.
Malheureusement, j'ai cassé mon projet en changeant les toolchains (ne jamais le faire si vous avez GNU BRAS Eclipse plugin installé!) mais c'est une autre histoire.
1 - C'est en vertu de l':
Project Properties > C/C++ General > Preprocessor Include Paths, Macros etc.
, l'ongletProviders
;Share settings entries between projects (global provider)
doit être désactivé pour modifier ce champ.OriginalL'auteur Manveru
veuillez noter que GNU BRAS Eclipse plugins ont été mis à jour en octobre 2013, et la nouvelle version a un meilleur support pour le chemin de la découverte, afin que ce problème est moins susceptible de se produire.
changer toolchains a également été corrigé.
ok. ma première tentative a été de poster un commentaire, mais il a été rejeté (pas assez de droits, ou quelque chose comme ça).
Bonjour Monsieur @LiviuIonescu ,Veuillez jeter un oeil à cette question: stackoverflow.com/questions/38033130/... je sais que vous êtes probablement l'une des seules personnes ayant une connaissance approfondie sur ce sujet. Je vous remercie beaucoup pour votre aide.
OriginalL'auteur ilg
Si vous êtes en utilisant un Makefile, Eclipse n'a aucun moyen de savoir où votre bibliothèque standard de la plate-forme cible est situé. La solution que j'ai trouvé, c'est pour ajouter de la bibliothèque des chemins de
Project->Preferences->C++ General->Paths and symbols
.OriginalL'auteur Vorac
J'ai eu le même problème et la solution de cette page a aidé à résoudre:
(gcc)|([gc]++)|(clang)
à(arm-none-eabi-gcc)|([gc]++)|(clang)
${COMMAND}
avecarm-none-eabi-gcc
.C'est parce que
${FLAGS}
doit être défini pour les drapeaux de compilation de votre fichier Makefile.OriginalL'auteur Vahid Shirvani
Dans
Project > Properties > C/C++ General > Preprocessor Include Paths > Providers
:Permettre
CDT GCC Built-in Compiler Settings Cross ARM
.Ensemble
Command to get compiler specs
:.C
sur la fin. C'est généralement fixé en fonction de la langue. Un petit.c
est utilisé pour du code C, tandis que le grand C est utilisé pour le C++. Mais il n'y a pas les langues spécifiées lors de l'utilisation d'un fichier make externe ou avec lano toolchain
option.Vérifiez également
Allocate console in the Console View
pour vérifier que la commande s'exécute correctement et les variables sont correctement substitué.Permettre
CDT GCC Build Output Parser
et modifier le compilateur modèle de commande de(gcc)|([gc]\+\+)|(clang)
à(.*g++)|(.*gcc)|(.*[gc]\+\+)
puis appliquer les modifications. Utiliser leMove up/down
boutons pour déplacer au-dessus de laCDT GCC Built-in Compiler Settings Cross ARM
.Vous aurez également besoin de mettre
Project > Properties > C/C++ General > Preprocessor Include Paths > Entries > CDT User Settings Entries
à la suivante:Dans
Preferences > String Substitutions
vous aurez besoin de créer un var pourgnu-arm-path
pointant vers votre chaîne de traitement à la maison.Idéalement, elles devraient être trouvés dans
CDT GCC Built-in Compiler Settings Cross ARM
, mais dans mon cas, ils ne le sont pas. Je pense que c'est à voir avec le fait que, dans un projet géré par, ces entrées sont liées à chaque langue. Mais avec un makefile la liste des langues juste dit[Unspecified]
.L'Éclipse scanner fournisseur de système semble être conçus autour de la CDT a géré des projets, c'est donc un peu plus compliqué à faire fonctionner, lorsque vous êtes à l'aide d'un makefile.
Vous pouvez créer un nouveau projet géré avec un makefile et vue sur le scanner de la découverte de la console pour voir comment il convient de travail. C'est ce que j'ai fait.
OriginalL'auteur vaughan
Je suis tombé sur une solution complètement différente de ma version de ce fameux problème. Dans mon cas, les chemins de recherche où pas le problème, car le compilateur ne marchait très bien. Cependant, l'editeur se plaignait en suspens cstdint types partout: très ennuyeux. Googler pour la solution à l'aide de la chaîne de message d'erreur n'a pas été fructueuse et très frustrant.
J'ai trouvé la solution de ce problème par hasard dans une réponse ("Il y a maintenant une nouvelle façon de résoudre ce problème sans le GXX_EXPERIMENTAL hack") pour le fil de discussion suivant:
Eclipse CDT C++11/C++0x soutien
Acclamations
OriginalL'auteur Anton