我为 C/C++ 开发人员安装了 Eclipse Juno 以及来自http://sourceforge.net/projects/gnuarmeclipse的 GNU ARM C/C++ 开发支持插件。
uint_32t在我的项目中，我使用的类型int16_t比uint8_t通常来自stdint.h. 虽然我通过直接指向目录所在的目录来强制 Eclipse 查看我的编译器的标准头文件include，但提到的类型没有被解析。这给了我很多关于未解析符号的红色标记，并且在使用这些类型声明的函数的代码完成方面出现了一些问题。
同样的问题出现在像GNUC这样的标准宏定义上——通常 CDT 会看到这些用于 GNU C 或 GNU C++，但将工具链设置为 ARM Windows GCC 则不会。奇怪的。
我能做些什么来解决这个问题并恢复 Eclipse 在生产力方面的主要提升？
我想我找到了解决问题的方法。问题是CDT GCC 内置编译器设置提供程序，它试图运行gcc而不是arm-elf-gcc. 我在字段 ¹ 中添加了前缀，以Command to get compiler specs:通过其正确名称调用编译器。
瞧，所有未解决的符号都消失了。
不幸的是，我通过更改工具链破坏了我的项目（如果您安装了 GNU ARM Eclipse 插件，则永远不要这样做！）但这是另一回事。
¹ - 它位于: Project Properties > C/C++ General > Preprocessor Include Paths, Macros etc., 选项卡下Providers; Share settings entries between projects (global provider)必须禁用才能编辑该字段。
请注意，GNU ARM Eclipse插件于 2013 年 10 月更新，新版本对路径发现的支持更好，因此出现此问题的可能性较小。
更改工具链也已修复。
如果您使用外部 Makefile，Eclipse 无法知道您的目标平台标准库的位置。我发现的解决方案是将库包含路径添加到
Project->Preferences->C++ General->Paths and symbols.
在Project > Properties > C/C++ General > Preprocessor Include Paths > Providers：
启用CDT GCC Built-in Compiler Settings Cross ARM.
设置Command to get compiler specs为：
arm-none-eabi-g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD "${INPUTS}".C
.C最后。这通常根据语言设置。small.c用于 C 代码，而 big C 用于 C++。但是在使用外部 makefile 或no toolchain选项集时没有指定语言。此外，检查Allocate console in the Console View命令是否正常运行以及变量是否被正确替换。
启用CDT GCC Build Output Parser并更改编译器命令模式(gcc)|([gc]\+\+)|(clang)，(.*g++)|(.*gcc)|(.*[gc]\+\+)然后应用更改。使用Move up/down按钮将其移动到 上方CDT GCC Built-in Compiler Settings Cross ARM。
您还需要设置Project > Properties > C/C++ General > Preprocessor Include Paths > Entries > CDT User Settings Entries以下内容：
在Preferences > String Substitutions您将需要创建一个gnu-arm-path指向您的工具链主页的 var。
理想情况下，这些应该在 中找到CDT GCC Built-in Compiler Settings Cross ARM，但在我的情况下它们不是。我认为这与在托管项目中这些条目与每种语言相关联的事实有关。但是对于外部 makefile，语言列表框只会显示[Unspecified].
Eclipse 扫描程序提供程序系统似乎是围绕 CDT 管理的项目设计的，这使得在使用外部 makefile 时开始工作有点棘手。
您可以使用外部 makefile 创建一个新的托管项目，并查看扫描仪发现控制台以了解它应该如何工作。这就是我所做的。
我遇到了同样的问题，这个页面的解决方案帮助解决了这个问题：
(gcc)|([gc]++)|(clang)为(arm-none-eabi-gcc)|([gc]++)|(clang)${COMMAND}为arm-none-eabi-gcc.我遇到了一个完全不同的解决方案来解决这个（不）著名问题的版本。在我的情况下，搜索路径不是问题，因为编译器工作正常。尽管如此，编辑还是到处抱怨无法解析的 cstdint 类型：非常烦人。使用错误消息字符串在谷歌上搜索解决方案没有成果，而且非常令人沮丧。
我偶然在以下线程的答案中找到了这个问题的解决方案（“现在有一种新方法可以在没有 GXX_EXPERIMENTAL hack 的情况下解决这个问题”）：
干杯
就我而言，问题在于它PATH没有直接指向编译器。所以我添加C:\Program Files (x86)\GNU Tools ARM Embedded\7 2017-q4-major\bin到变量中并且它起作用了。澄清一下：我们有一个约定，我们使用变量指向编译器GCCPATH。
查看 Project -> C/C++ Index -> Freshen All Files 是否有帮助。