带有CDT的Eclipse 3.7.0 Indigo显示了许多错误的编译错误

时间:2023-01-24 22:00:32

I have updated my Ubuntu box to 11.10 and then Eclipse also have been updated to 3.7.0 Indigo with CDT 8.0.1

我已将我的Ubuntu框更新为11.10,然后Eclipse也已更新为3.7.0 Indigo和CDT 8.0.1

Then the following problem occurs:

然后出现以下问题:

带有CDT的Eclipse 3.7.0 Indigo显示了许多错误的编译错误

I have included the vector header file but the compiler said that Symbol 'vector' could not be resolved. I also defined #define int Comparable, but Eclipse also said Symbol 'Comparable' could not be resolved and so on....

我已经包含了矢量头文件,但编译器说无法解析符号'矢量'。我还定义了#define int Comparable,但是Eclipse也说Symbol'Comparable'无法解析等等....

Although lots of errors occur, compiling was finished successfully!

虽然发生了很多错误,但编译成功完成!

I have tried to use g++ to compile the code, it had no problem.

我试过用g ++编译代码,没问题。

8 个解决方案

#1


5  

Time after time a crash of Eclipse, the VM or the computer or even just long months of development start to wear down the stability of the workspace where Eclipse stores everything.

Eclipse,VM或计算机崩溃或者甚至长达几个月的开发一次又一次地开始削弱Eclipse存储所有内容的工作空间的稳定性。

Check the <workspace dir>\.metadata directory to get an idea of just how much Eclipse generates and stores in your workspace. Every time you add a plugin, upgrade a plugin, remove a plugin that puts and changes information in your workspace.

检查 \ .metadata目录,了解Eclipse在工作区中生成和存储的数量。每次添加插件时,请升级插件,删除放置和更改工作区中信息的插件。

A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).

一个证据就是这个问题通常在升级Eclipse之后出现。 (就我而言,给Indigo)。

The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.

修复尘土工作区的最简单方法是使用eclipse.exe可执行文件的-clean命令行参数。

Eclipse help docs tell us what this command does:

Eclipse帮助文档告诉我们这个命令的作用:

if set to "true", any cached data used by the OSGi framework and eclipse runtime will be wiped clean. This will clean the caches used to store bundle dependency resolution and eclipse extension registry data. Using this option will force eclipse to reinitialize these caches.

如果设置为“true”,则OSGi框架和eclipse运行时使用的任何缓存数据都将被清除。这将清除用于存储bundle依赖项解析和eclipse扩展注册表数据的缓存。使用此选项将强制eclipse重新初始化这些缓存。

There are three ways one can use the -clean command line argument:

有三种方法可以使用-clean命令行参数:

  1. Edit the eclipse.ini file located in your and add it as the first argument on the first line.
  2. 编辑位于您的eclipse.ini文件,并将其添加为第一行的第一个参数。

  3. Edit the shortcut you use to start Eclipse and add it as the first argument.
  4. 编辑用于启动Eclipse的快捷方式,并将其添加为第一个参数。

  5. Create a batch or shell script that calls the Eclipse executable with the -clean argument.
  6. 创建一个批处理或shell脚本,使用-clean参数调用Eclipse可执行文件。

The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.

步骤3的优点是您可以保留脚本并在每次要清理工作区时使用它。

This page solved the problem to me!Hope it can help everybody else.

这个页面解决了我的问题!希望它可以帮助其他人。

#2


8  

The problem is that there are a bunch of include directories that are missing from the indexer's perspective.

问题是索引器的角度中缺少一堆包含目录。

Adding the following worked for me, but may depend on your particular setup where they actually exist:

添加以下内容对我有用,但可能取决于您实际存在的特定设置:

/usr/include/c++/4.6.1
/usr/include/                
/usr/include/c++             
/usr/include/c++/4.6         
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/

They can be set in Project>Properties>C++ Include Paths

可以在Project> Properties> C ++ Include Paths中设置它们

Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.

据推测,在未来,CDT的平台专业化将自动包含这些。我记得在某处读过,但无法提供参考。

#3


2  

In the project properties, go to C/C++ Build > Tool Chain Editor, tick Display compatible toolchains only, and select Linux GCC and click Apply button.

在项目属性中,转到C / C ++ Build> Tool Chain Editor,仅勾选Display compatible toolchains,然后选择Linux GCC并单击Apply按钮。

Now if you go to C\C++ General > Paths and Symbols, you will see new list of include paths added. If you rebuild index, the error messages should go away.

现在,如果您转到C \ C ++ General> Paths and Symbols,您将看到添加的新路径列表。如果重建索引,错误消息应该消失。

#4


1  

The code analysis is causing this. It's not actually compiling the code but just doing some static checks for quick feedback. Unfortunately I don't know how to fix it, I just disabled it. Sorry I'm at work so I don't have CDT in front of me but I think it's something like:

代码分析导致了这一点。它实际上并没有编译代码,只是做了一些静态检查以获得快速反馈。不幸的是我不知道如何解决它,我只是禁用它。对不起,我在工作,所以我没有CDT在我面前,但我认为它是这样的:

Window > Preferences > C++ General > Code Analysis

Go there and un-check all the boxes to disable it.

去那里取消选中所有框以禁用它。

#5


1  

When you create a C++ project (in my case from existing code) you have to set the 'Toolchain for Indexer Settings' to the compiler you use ('GNU Autotools Toolchains' in my case). After this 'Path and Symbols' will show the correct path to the include files of your compiler. The bugs will disappear. This setting was useful only during creating the project, setting it later did not help.

当你创建一个C ++项目(在我的情况下来自现有代码)时,你必须将'Toolchain for Indexer Settings'设置为你使用的编译器(在我的例子中是'GNU Autotools Toolchains')。在此之后,“路径和符号”将显示编译器的包含文件的正确路径。错误将消失。此设置仅在创建项目期间有用,稍后设置它无济于事。

In indigo 3.7.2 version (and up may be) your changes can be effect after reindexing. Eclipse ask for "reindexing". Lower versions can require a manual reindexing header tags etc.

在indigo 3.7.2版本(以及更新版本)中,您的更改可能会在重建索引后生效。 Eclipse要求“重新索引”。较低版本可能需要手动重建索引标头等。

#6


1  

Updated index option to active build configuration works for me,

更新的活动构建配置索引选项适用于我,

also I removed some files from the file list of being indexed up-front,

我还从前面索引的文件列表中删除了一些文件,

#7


0  

Ok here is what worked for me:

好的,这对我有用:

  • deleted the path to the header files I created from the include path

    删除了我从include路径创建的头文件的路径

  • compiled the project (obviously the compiler complains since it is missing user-defined headers)

    编译项目(显然编译器抱怨,因为它缺少用户定义的头文件)

  • reinserted the path to the header files I created

    重新插入我创建的头文件的路径

  • compiled the project again - worked perfectly

    再次编译项目 - 完美地工作

I can't explain the case :(

我无法解释这个案子:(

#8


0  

I am answering here because this is the closest question to my problem.

我在这里回答,因为这是我问题最接近的问题。

I used QT Eclipse integration with Helios (3.6.2) with no major problems. I was using mingw 4.6.2, which I had installed to c:\mingw. I wanted to upgrade to Indigo, which fixed some minor issues I was having with CDT.

我使用QT Eclipse与Helios(3.6.2)集成,没有出现重大问题。我正在使用mingw 4.6.2,我已经安装到c:\ mingw。我想升级到Indigo,它修复了我在CDT上遇到的一些小问题。

However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:

然而,在Indigo(3.7 SR2)下,Eclipse开始强调琐碎的功能,因为没有解决,例如:

function 'fprintf' could not be resolved
function 'memset' could not be resolved

even though #include was not underlined, could be opened, and included fprintf in the header. And even though the code itself compiled fine.

即使#include没有加下划线,也可以打开,并在标题中包含fprintf。即使代码本身编译得很好。

If I went back to Helios, the problems went away.

如果我回到Helios,问题就消失了。

I tried reindexing, to no avail. I checked my include paths, and they were:

我尝试重新索引,无济于事。我查看了包含路径,它们是:

c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include

At first, I had just included the first, but not the second. But then I searched for "unresolved includes", and stdio.h was including stdarg.h, which wasn't in the main include folder of mingw, so I added the second. But still, printf was not resolved, and there were no more "unresolved includes".

起初,我刚刚包括第一个,但不是第二个。但后来我搜索了“unresolved includes”,而stdio.h包含了stdarg.h,它不在mingw的主要include文件夹中,所以我添加了第二个。但是,仍然没有解决printf问题,也没有“未解决的问题”。

I created a new C++ project with one class. I added stdio.h, the paths above, and a call to fprintf. It was underlined! Even though other things from stdio were not underlined.

我用一个类创建了一个新的C ++项目。我添加了stdio.h,上面的路径,以及对fprintf的调用。它有下划线!尽管stdio中的其他内容没有得到强调。

Now I knew that it wasn't just a Qt problem.

现在我知道这不仅仅是Qt问题。

I worked around on this for a while before I read the bottom post here suggesting removing the include paths and compiling. I didn't believe it would work but gave it a shot. Amazingly, even though the compile failed, the error went away!

在我阅读底部帖子之前,我在这方面工作了一段时间,建议删除包含路径和编译。我不相信它会起作用但是给了它一个机会。令人惊讶的是,即使编译失败,错误也消失了!

It was then that I took another look at the include paths. They had been updated by the compile step to the following:

就在那时我又看了一下包含路径。它们已在编译步骤中更新为以下内容:

c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++

These were marked as "built-in" values which I assume means they weren't added by me and could get updated the next time I run a build.

这些被标记为“内置”值,我认为这意味着它们不是由我添加的,并且可以在下次运行构建时更新。

So, I guess the lesson is, including every single include path under mingw, even if Eclipse doesn't find it to be an unresolved include.

所以,我猜的教训是,包括mingw下的每一个包含路径,即使Eclipse没有发现它是一个未解析的包含。

The next step was to put all these paths into my Qt project. Unfortunately, after doing so, the unresolved functions were still there. It appears to be some sort of bug with the Qt C/C++ include paths which are different from the CDT C/C++ include paths.

下一步是将所有这些路径放入我的Qt项目中。不幸的是,在这样做之后,尚未解决的功能仍然存在。它似乎是Qt C / C ++包含路径的某种错误,这些路径与CDT C / C ++包含路径不同。

#1


5  

Time after time a crash of Eclipse, the VM or the computer or even just long months of development start to wear down the stability of the workspace where Eclipse stores everything.

Eclipse,VM或计算机崩溃或者甚至长达几个月的开发一次又一次地开始削弱Eclipse存储所有内容的工作空间的稳定性。

Check the <workspace dir>\.metadata directory to get an idea of just how much Eclipse generates and stores in your workspace. Every time you add a plugin, upgrade a plugin, remove a plugin that puts and changes information in your workspace.

检查 \ .metadata目录,了解Eclipse在工作区中生成和存储的数量。每次添加插件时,请升级插件,删除放置和更改工作区中信息的插件。

A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).

一个证据就是这个问题通常在升级Eclipse之后出现。 (就我而言,给Indigo)。

The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.

修复尘土工作区的最简单方法是使用eclipse.exe可执行文件的-clean命令行参数。

Eclipse help docs tell us what this command does:

Eclipse帮助文档告诉我们这个命令的作用:

if set to "true", any cached data used by the OSGi framework and eclipse runtime will be wiped clean. This will clean the caches used to store bundle dependency resolution and eclipse extension registry data. Using this option will force eclipse to reinitialize these caches.

如果设置为“true”,则OSGi框架和eclipse运行时使用的任何缓存数据都将被清除。这将清除用于存储bundle依赖项解析和eclipse扩展注册表数据的缓存。使用此选项将强制eclipse重新初始化这些缓存。

There are three ways one can use the -clean command line argument:

有三种方法可以使用-clean命令行参数:

  1. Edit the eclipse.ini file located in your and add it as the first argument on the first line.
  2. 编辑位于您的eclipse.ini文件,并将其添加为第一行的第一个参数。

  3. Edit the shortcut you use to start Eclipse and add it as the first argument.
  4. 编辑用于启动Eclipse的快捷方式,并将其添加为第一个参数。

  5. Create a batch or shell script that calls the Eclipse executable with the -clean argument.
  6. 创建一个批处理或shell脚本,使用-clean参数调用Eclipse可执行文件。

The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.

步骤3的优点是您可以保留脚本并在每次要清理工作区时使用它。

This page solved the problem to me!Hope it can help everybody else.

这个页面解决了我的问题!希望它可以帮助其他人。

#2


8  

The problem is that there are a bunch of include directories that are missing from the indexer's perspective.

问题是索引器的角度中缺少一堆包含目录。

Adding the following worked for me, but may depend on your particular setup where they actually exist:

添加以下内容对我有用,但可能取决于您实际存在的特定设置:

/usr/include/c++/4.6.1
/usr/include/                
/usr/include/c++             
/usr/include/c++/4.6         
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/

They can be set in Project>Properties>C++ Include Paths

可以在Project> Properties> C ++ Include Paths中设置它们

Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.

据推测,在未来,CDT的平台专业化将自动包含这些。我记得在某处读过,但无法提供参考。

#3


2  

In the project properties, go to C/C++ Build > Tool Chain Editor, tick Display compatible toolchains only, and select Linux GCC and click Apply button.

在项目属性中,转到C / C ++ Build> Tool Chain Editor,仅勾选Display compatible toolchains,然后选择Linux GCC并单击Apply按钮。

Now if you go to C\C++ General > Paths and Symbols, you will see new list of include paths added. If you rebuild index, the error messages should go away.

现在,如果您转到C \ C ++ General> Paths and Symbols,您将看到添加的新路径列表。如果重建索引,错误消息应该消失。

#4


1  

The code analysis is causing this. It's not actually compiling the code but just doing some static checks for quick feedback. Unfortunately I don't know how to fix it, I just disabled it. Sorry I'm at work so I don't have CDT in front of me but I think it's something like:

代码分析导致了这一点。它实际上并没有编译代码,只是做了一些静态检查以获得快速反馈。不幸的是我不知道如何解决它,我只是禁用它。对不起,我在工作,所以我没有CDT在我面前,但我认为它是这样的:

Window > Preferences > C++ General > Code Analysis

Go there and un-check all the boxes to disable it.

去那里取消选中所有框以禁用它。

#5


1  

When you create a C++ project (in my case from existing code) you have to set the 'Toolchain for Indexer Settings' to the compiler you use ('GNU Autotools Toolchains' in my case). After this 'Path and Symbols' will show the correct path to the include files of your compiler. The bugs will disappear. This setting was useful only during creating the project, setting it later did not help.

当你创建一个C ++项目(在我的情况下来自现有代码)时,你必须将'Toolchain for Indexer Settings'设置为你使用的编译器(在我的例子中是'GNU Autotools Toolchains')。在此之后,“路径和符号”将显示编译器的包含文件的正确路径。错误将消失。此设置仅在创建项目期间有用,稍后设置它无济于事。

In indigo 3.7.2 version (and up may be) your changes can be effect after reindexing. Eclipse ask for "reindexing". Lower versions can require a manual reindexing header tags etc.

在indigo 3.7.2版本(以及更新版本)中,您的更改可能会在重建索引后生效。 Eclipse要求“重新索引”。较低版本可能需要手动重建索引标头等。

#6


1  

Updated index option to active build configuration works for me,

更新的活动构建配置索引选项适用于我,

also I removed some files from the file list of being indexed up-front,

我还从前面索引的文件列表中删除了一些文件,

#7


0  

Ok here is what worked for me:

好的,这对我有用:

  • deleted the path to the header files I created from the include path

    删除了我从include路径创建的头文件的路径

  • compiled the project (obviously the compiler complains since it is missing user-defined headers)

    编译项目(显然编译器抱怨,因为它缺少用户定义的头文件)

  • reinserted the path to the header files I created

    重新插入我创建的头文件的路径

  • compiled the project again - worked perfectly

    再次编译项目 - 完美地工作

I can't explain the case :(

我无法解释这个案子:(

#8


0  

I am answering here because this is the closest question to my problem.

我在这里回答,因为这是我问题最接近的问题。

I used QT Eclipse integration with Helios (3.6.2) with no major problems. I was using mingw 4.6.2, which I had installed to c:\mingw. I wanted to upgrade to Indigo, which fixed some minor issues I was having with CDT.

我使用QT Eclipse与Helios(3.6.2)集成,没有出现重大问题。我正在使用mingw 4.6.2,我已经安装到c:\ mingw。我想升级到Indigo,它修复了我在CDT上遇到的一些小问题。

However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:

然而,在Indigo(3.7 SR2)下,Eclipse开始强调琐碎的功能,因为没有解决,例如:

function 'fprintf' could not be resolved
function 'memset' could not be resolved

even though #include was not underlined, could be opened, and included fprintf in the header. And even though the code itself compiled fine.

即使#include没有加下划线,也可以打开,并在标题中包含fprintf。即使代码本身编译得很好。

If I went back to Helios, the problems went away.

如果我回到Helios,问题就消失了。

I tried reindexing, to no avail. I checked my include paths, and they were:

我尝试重新索引,无济于事。我查看了包含路径,它们是:

c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include

At first, I had just included the first, but not the second. But then I searched for "unresolved includes", and stdio.h was including stdarg.h, which wasn't in the main include folder of mingw, so I added the second. But still, printf was not resolved, and there were no more "unresolved includes".

起初,我刚刚包括第一个,但不是第二个。但后来我搜索了“unresolved includes”,而stdio.h包含了stdarg.h,它不在mingw的主要include文件夹中,所以我添加了第二个。但是,仍然没有解决printf问题,也没有“未解决的问题”。

I created a new C++ project with one class. I added stdio.h, the paths above, and a call to fprintf. It was underlined! Even though other things from stdio were not underlined.

我用一个类创建了一个新的C ++项目。我添加了stdio.h,上面的路径,以及对fprintf的调用。它有下划线!尽管stdio中的其他内容没有得到强调。

Now I knew that it wasn't just a Qt problem.

现在我知道这不仅仅是Qt问题。

I worked around on this for a while before I read the bottom post here suggesting removing the include paths and compiling. I didn't believe it would work but gave it a shot. Amazingly, even though the compile failed, the error went away!

在我阅读底部帖子之前,我在这方面工作了一段时间,建议删除包含路径和编译。我不相信它会起作用但是给了它一个机会。令人惊讶的是,即使编译失败,错误也消失了!

It was then that I took another look at the include paths. They had been updated by the compile step to the following:

就在那时我又看了一下包含路径。它们已在编译步骤中更新为以下内容:

c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++

These were marked as "built-in" values which I assume means they weren't added by me and could get updated the next time I run a build.

这些被标记为“内置”值,我认为这意味着它们不是由我添加的,并且可以在下次运行构建时更新。

So, I guess the lesson is, including every single include path under mingw, even if Eclipse doesn't find it to be an unresolved include.

所以,我猜的教训是,包括mingw下的每一个包含路径,即使Eclipse没有发现它是一个未解析的包含。

The next step was to put all these paths into my Qt project. Unfortunately, after doing so, the unresolved functions were still there. It appears to be some sort of bug with the Qt C/C++ include paths which are different from the CDT C/C++ include paths.

下一步是将所有这些路径放入我的Qt项目中。不幸的是,在这样做之后,尚未解决的功能仍然存在。它似乎是Qt C / C ++包含路径的某种错误,这些路径与CDT C / C ++包含路径不同。