So I am building some Arduino code in eclipse, as described in Your Second Arduino Project, but every time I use an Arduino library, such as Serial, Eclipse underlines my function names, claiming they cannot be resolved. However, the code actually compiles, so I'm kind of at a loss as to why Eclipse thinks the functions are missing. If anyone has any idea on how to solve this problem it would be appreciated. Thanks beforehand.
EDIT: I should have been more specific, Eclipse underlines the METHODS inside the Arduino libraries. So if I use Serial.println("hello");, it underlines println() and claims it cannot be resolved. Then it compiles just fine and the method works when uploaded to the arduino board.
EDIT2: I found my error, turns out I was trying to use some C++ functions in a C file, and eclipse didn't like it; I renamed to .cpp and all the red disappeared ;) Thanks for your help!
Eclipse may or may not be pulling the paths to index from your build setup, depending on the configuration. Most likely, it is not...it's building correctly because your build setup is just fine, and you can probably build by hand.
The CDT indexer (which is the engine for deciding where all those pretty underlines, as well as code completion, F3 declaration jumping, etc comes from) isn't smart enough in a lot of cases to parse out your Makefiles and know where to look for headers and source. You need to tell Eclipse that information manually.
Go to Project Properties -> C/C++ General -> Paths and Symbols.
The amount of work you need to put into this can vary greatly, depending on your environment. If this external library is the only thing giving you headaches, then you probably just need to add the paths for that library and reindex:
Right-click on the project and select Index -> Rebuild
For starters, what color is the underline? This makes a difference, as yellow means it's a warning, and red means it's an error (critical, will not build in most circumstances).
Second, you need to look at the "Problems" tab to see if there are actual errors. If there is nothing there, then it did indeed compile correctly.
Now, back to the original question. Depending on the type of project you are building, this type of behavior is not that uncommon. Eclipse seems to do a poor job of indexing certain projects. When you run "make all" from the command line (which is effectively what Eclipse does during build) it is likely resolving all of your code and building it just fine.
However, Eclipse uses a different, separate tool for indexing all of your source code and resolving variable/function definitions and declarations. This is literally a case of the left hand not knowing what the right hand is doing.
The solution below worked for me:
Click to your project using right click. Then: Properties -> C/C++ General -> Paths and Symbols -> Symbols -> GNU C++.
Almost for sure there are no symbols at all if you have this problem. Add symbol "__cplusplus" with value "201402L"
After this:
Right click on Project -> Index -> Rebuild
You are done.
I had include folders in
Project Properties -> C/C++ General -> Paths and Symbols -> Includes
When I removed those, the red underlines went away, i.e. the build and the IDE where in sync.
When resolving symbols, CDT indexer seems to consider all header files irrespectively of which ones are actually included in the compilation unit. There is a corresponding bug report filed with Eclipse Bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=439553
In my case the problem was due to adding "-std=c++17" flag in the language standard field in the project properties under the compile dialect. After that the build was passing with errors, but the program was running fine. So the trick of Index>Rebuild resolved everything.
If you changed something in the configurations, (example, editing in *.cproject file with notepad++) , the below options helps.
Build Configurations --> Clean All and then Index --> Rebuild
I had the same problem.
Index -> Rebuild didn't help.
When I added line #include <avr/iom1280.h> in main.cpp and made Index -> Rebuild underlines dissapeared.
Then I deleted line #include <avr/iom1280.h> and project still without inderlines.
Replace iom1280.h with name of your controller. Look at the "avr\include\avr\" folder for available names
Eclipse does not work as well with C++ as it does with Java, but it should warn you about issues once you press "Rebuild" in the menu bar.
Try that, and see if it resolves your problem.
Related
I'm having a problem with eclipse C++ juno. My project compiles and runs from command line but eclipse (juno) keeps saying there are thousands of errors. For example there's a function SetRun in my code, and eclipse mentions this error: "called Invalid arguments 'Candidates are: void SetRun(?)'", whereas SetRun is of type static void SetRun (uint32_t run);
I have quite a lot of similar errors like that, where eclipse doesn't seem to understand the type of the function and puts a '?' instead.
I also have many errors like this: "symbol '*' could not be resolved."
I also have many includes that can't be resolved, although they are resolved just fine by the compiler.
I think this is all part of the same issue.
I should also note that I had this working with eclipse previously, but now everytime I open eclipse it appears that way.
If I build the project from eclipse, it build successfully.
I tried updating the index but it didn't change a thing.
What can I do to make eclipse stop telling me about these errors?
edit:
here is an example of a include that is not resolved:
#include "ns3/core-module.h"
I had the same problem in my project. Try the following:
Right click on the project name
Then Index
Then Freshen All Files and wait.
This worked for me.
You have to manually add include and symbols paths in your project preferences. Follow this instructions. You can find a lot more information about it just goggling set up include paths eclipse.
It is normal that even though you Eclipse editor cannot resolve the path, your compiler can, because they use independent settings.
EDIT: Looks like in your case you are interested in using ns-3 in Eclipse, then you should follow this instructions.
In the past, i had too many issues with C++ projects under Eclipse that I eventually ended up switching to another IDE. Unless you really have to work under Eclipse, i suggest you switch to another one.
I'm using Vertex Array Objects and Vertex Buffer Objects in Eclipse, but the editor doesn't appear to recognize the function declarations. The program compiles and executes without any complaint.
(Note that the errors are "Function could not be resolved.")
I've tried using both GLee and GLEW, but the results are the same. Any ideas on how to get Eclipse to recognize the functions in the editor?
In general, OpenGL function pointers like this have to be defined by macros that resolve to some function name. That plays havoc with IDEs and their attempts to figure out what is going on.
Ultimately, if your IDE can't handle it, you'll just have to find a way to live with it.
I don't know if there is anything special about OpenGl Extensions but I do know in general I often have to dig down to the root folder that contains the .h files for my library and explicitly add all the folders to my include paths. Adding the topmost parent doesn't cut it for the editor. Once I add them all I then rebuild the indices (usually to get type-ahead features working). It's strange that the editor is more picky about this than the compiler but I have seen it happen with multiple libraries.
I had this exact problem, and the only thing that fixed it was to start a brand new C++ project, make the very first include #include <GL/glew.h>, and copy in the rest of the code. If the project is set up without glew.h as the first import, it never reconfigures itself for some reason.
I tried manually messing with the project and global properties in Eclipse; nothing worked except the above.
RE: Nicol Bolas's answer, it's true that Eclipse cannot parse the macros well enough to generate all the tooltips and autocompletes, but it will recognize the functions and enforce correct arguments.
Just make sure you have the most up-to-date version of Eclipse CDT (and GLEW).
In some occasions it might work when you rebuild the index (right-click project > Index > Rebuild)
I have mixed C++ / Java project in Eclipse. I've setup a build.mk file and Eclipse builds project successfully when all files in editor are closed. When I open a .h or a .cpp file Eclipse finds a lot of undefined symbols in them. I have references to 3rd party API and all the problems seem to be related to symbols from that API. Strangely, some types are considered defined in Eclipse, and some are considered undefined even though in some cases they are defined in the same .h file.
My colleague is not experiencing any of these problems, but we are clueless where to start solving this problem. We already made sure that our Eclipse include directories are the same. Is there some way to compare eclipse project settings?
Update: .cproject files and .project files and files in .settings directory know differ only by some paths. Did not help to solve my problem though.
I had the same problem. It could be resolved by flushing the Eclipse indexer.
I used the projects context menu and selected Index->Rebuild and Index->Freshen All Files. The last removed the error messages.
Turns out I needed to change Code Analysis settings that are on Launching tab, and I simply did not see that tab.
I had the same problem. It take place when in included file I'd used
namespace std
without using it in main file or vice versa. Do check using namespace equally.
You can compile and run the source code also by Right Click On Project>Run C/C++ Code Analysis. This will solve your problem.
I finally figured this out. Flushing the Eclipse Indexer as mentioned in the top voted answer didn't work for me. This is what I had to do:
I went to:
Project -> Properties -> C/C++ General -> Paths and Symbols -> Includes
Here I had the path for my include directory, but what I had to do was delete the directory path, and then re-add it making sure to check the box "Add to all configurations". I also checked the box "Add to all languages", but I don't think that is necessary.
After this, you may need to then click on Project -> C/C++ Index -> Rebuild. I didn't need to, but you might. Also, obviously instead of C/C++ in the paths above, it will be Java or whatever language you are dealing with.
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
Then the following problem occurs:
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....
Although lots of errors occur, compiling was finished successfully!
I have tried to use g++ to compile the code, it had no problem.
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
Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.
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.
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.
A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).
The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.
Eclipse help docs tell us what this command does:
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.
There are three ways one can use the -clean command line argument:
Edit the eclipse.ini file located in your and add it as the first argument on the first line.
Edit the shortcut you use to start Eclipse and add it as the first argument.
Create a batch or shell script that calls the Eclipse executable with the -clean argument.
The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.
This page solved the problem to me!Hope it can help everybody else.
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.
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.
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:
Window > Preferences > C++ General > Code Analysis
Go there and un-check all the boxes to disable it.
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.
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.
Updated index option to active build configuration works for me,
also I removed some files from the file list of being indexed up-front,
Ok here is what worked for me:
deleted the path to the header files I created from the include path
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 :(
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.
However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:
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.
If I went back to Helios, the problems went away.
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".
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.
Now I knew that it wasn't just a Qt problem.
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.
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.
I'm using Eclipse with C++ code via linked resources on Linux. The code analysis index seems to be corrupted (Goto definition lands the cursor close to, but not on, the definition) Refreshing resources doesn't fix it, neither does restarting Eclipse.
Is there a way to flush the index and rebuild it?
Right-click on your project, go under the Index submenu, and choose either "Rebuild," "Update with modified files," or "Freshen all files."
I don't know the difference between those three options, but one of "Update with modified files" or "Freshen all files" usually fixes it for me.
Also, I'm sure you've already done this, but make sure that you're running the latest version of the Eclipse CDT. Current versions seem to have much more reliable indexing than previous versions.
From http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg10390.html, the differences between "Rebuild," "Update with modified files," or "Freshen all files":
Rebuild: Works for entire projects, only. Clears the index and indexes
the files from scratch. When cancelled it leaves you with an empty or
partial index.
Update with Modified Files: Works on a resource
selection. Checks on individual files whether the timestamp or the
scanner-config has been changed and updates the index for the changed
files.
Freshen All Files: Works on a resource selection. Updates the
selected files in the index. The index is not cleared, it is safe to
cancel the operation.
Go to your project properties -> C++ general -> Indexer.
Do this with 'project specific settings',
(or on 'Configure Workspace Settings...').
Deselect 'Enable Indexer' hit Apply.
Select 'Enable Indexer' hit Apply.
This should completely wipe out and rebuild the index.
Neither of the above worked for me (Eclipse Indigo), index still broken and refusing to rebuild properly. Until applied this one:
http://slsam2.blogspot.com/2012/02/eclipse-cdt-index-not-working.html
The crucial bit of the linked post is this:
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code.
I still wonder how Eclipse can uncontrollably shoot itself in the foot like that. I suspect that installing additional packages can trigger it. Perhaps JavaScript support in my case.
delete only the .pdom file under .metadata.plugins\org.eclipse.cdt.core helps, I got the indexer screwed after upgrading Neon.2 to Neon.3 and this seems to solve the problem.
(this comment already exists above but am not allowed to confirm it up there).
I found that I had the global indexer set to 'Use the build configuration specified in the project's indexer settings',
and the project's indexer set to NOT use project specific indexer settings.
Regardless, it was using the same fixed configuration for the indexer regardless of which configuration I had selected.
The fix:
Window-Preferences, C/C++, Indexer. Select "Use active build configuration" in section "Build configuration for the indexer".
Happy days.
Did you try adding -clean to the command line for the eclipse executable?
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code. worked for me
I started with trying Josh Kelleys and mmmmms answers without any luck, but I finally fixed it by checking my include paths.
One way to see them are in the Project Explorer, expand project and there should be an entry "Includes". Inside that, check for a small yellow warning triangle on each include path. If that triangle is present eclipse most likely doesn't recognize the path.
The include paths are edited through right-clicking on "Your project" in the Project explorer, then choose "Properties" --> C/C++ General --> Paths and Symbols --> Includes.
I see three language options, Assembly, Gnu C, Gnu C++. Choose the correct one before starting to add paths (likely Gnu C++). After adding all the paths, -->Apply --> Ok and rebuild index if you're asked to.
My erroneous workspace paths looked like MyProject/MyProject/folder when it was supposed to be MyProject/folder.
For me the "Problems"-view is always slow to update, even after rebuilding index. To be sure that the error is still there, double-click the problems entry so that eclipse opens/reloads the file in question. This often seems necessary for me to update the "Problems" view.
I don't really know if it was eclipse or my scm that messed it up. Anyway, hope it helps someone!
I use Luna and builds with an external makefile.