I setup Eclipse C++ - Version: Neon Release (4.6.0) - Build id: 20160613-1800 - with the GNU gcc ARM Embedded Toolchain (not gcc4mbed). The toolchain works great, but I ran into an issue involving (I think) Eclipse's indexer on my latest project.
My problem should be clear if I give the steps to reproduce my issue:
Create some class and #include "mbed.h"
Declare some member variable of type DigitalOut. Notice that Eclipse recognizes this just fine because the text turns bold, and code completion works fine when interacting with the variable.
Declare another member variable of type PwmOut. Notice that Eclipse does NOT recognize this, the text does not turn bold, and code completion doesn't work because Eclipse doesn't know what a PwmOut is. Eclipse says:
Errors (1 item)
Type 'PwmOut' could not be resolved. - main.cpp - Semantic Error
Build project completes successfully, compiler throws no errors, even though Eclipse still does not recognize PwmOut. Binary runs correctly on my LPC1768.
How is it possible that Eclipse can recognize DigitalOut but not PwmOut? Both are listed in the same code block inside mbed.h--and DigitalOut.h is in the same directory as PwmOut.h.
If it helps, here is an example project I exported from developer.mbed.org that you can import into Eclipse C++ as an existing Makefile project.
I have tried adapting suggestions I found such as adding the directory with these headers in Project->Properties->C/C++ General->Paths and Symbols->Includes, rebuilding the index, and "Freshening" all files in the index. I just can't get Eclipse to recognize them.
EDIT: I'd like to add that if I click on the "Type 'PwmOut' could not be resolved" error message in the "Problems" window, Eclipse locks up for a few seconds, then crashes with a stack overflow.
I am sorry to say that my solution probably isn't very generalizable or helpful to other people's Eclipse C++ issues.
Solution:
In your developer.mbed.org exported project folder, find the file "device.h" located in the mbed subdirectory at
./mbed/TARGET_LPC1768/TARGET_NXP/TARGET_LPC176X/TARGET_MBED_LPC1768/device.h
Mine was more or less empty.
Replace this device.h with the one located at the mbed official repo for the LPC1768.
Notice this device.h has a bit more detail in it.
Rebuild Eclipse's index. Eclipse should now be happy.
My interpretation of why this fixes Eclipse's problem:
When you export a project from developer.mbed.org, it gives you a zip with all your sources, as well as an "./mbed" directory that contains the header files and objects for the specific microcontroller with which you're working.
Most of NXP/ARM's controllers should have some variation of a DigitalOut or DigitalIn class, since that kind of functionality is very basic and common to a controller. However, this particular chip (the LPC1768) has an independent module onboard to handle pulse width modulation. This module might not be found on all of NXP/ARM's chips, so you can think of this as a special case we need to take care of when setting up a workspace environment in an IDE such as Eclipse.
Particularly, the mbed exported project contains a header located (for me) at
./mbed/TARGET_LPC1768/TARGET_NXP/TARGET_LPC176X/TARGET_MBED_LPC1768/device.h
This device header should define preprocessor directives specific to the device you're programming. Mine was empty, but the one at the official repo for the LPC1768 has a lot of #defines in it for this controller. As long as the DEVICE_PWMOUT directive in device.h is defined to be equal to 1 (and it is), Eclipse will know that it is supposed to recognize the PwmOut class.
Related
I'm currently working with a very small team on a project in C++ that involves displaying an image. We wish to be able to collaborate on it by sharing the code in a remote Git repository, and to this end, we have all agreed to switch to using Eclipse CDT instead of Xcode/Visual Studio/whatever else. Ideally, we should be able to clone the repository onto any machine with Eclipse CDT (and the relevant libraries) installed and build then successfully run the code there without any changes to it, but the current working version of the code uses the path of an image from my user directory. I have a copy of that image inside the project, and my question is, how can I use that so my teammates can use it too?
I've tried to use a relative path (which I've heard would find it relative to where the executable is run from rather than where it is anyhow), and I've tried substituting PROJECT_PATH for various prefixes of the full absolute path, but neither has worked. I'm also aware that the path of the image could be passed as a command-line argument, but I would prefer to have it inside the project, and although it could be appropriate in this situation I can think of many more in which it would not be (loading a sprite for a game, for example), and it just bothers me to not know how to do something that ought to be so basic.
A good bit of searching Stack Overflow has come up with many solutions to similar problems, but what little I've found for C++ has been for Visual Studio or Code::Blocks, and what little I've found for Eclipse has been for Java. It all seems to involve either "resource loaders" or directly shoving the relevant data into the binary, but I haven't been able to find documentation for these "resource loaders" and integrating the data into the executable using a hex editor seems like a lot of extra work to do each time the project gets built (plus I haven't a clue how to make it work with the library functionality I'm using).
The version of Eclipse IDE for C/C++ Developers that I'm using is 2018-12 (4.10.0), on macOS Mojave 10.4.2, and the single teammate I've interacted with so far is on some-or-another version of Ubuntu running presumably the same version of Eclipse. We should both be able to build and run the project, using the image, from the same files cloned from the same Git repository. The project is a "C++ Managed Build", because I couldn't figure out how to get the "CMake Project" to work (plus I don't know how to use CMake either way), with the "MacOSX GCC" toolchain (which come to think of it is probably another issue with moving the code between systems, but that's a problem for another day) because I have no idea how to use the "Cross GCC" toolchain.
This problem seems general enough that it shouldn't much matter, but the exact line of code that needs the path to the image currently looks like
cv::Mat image = cv::imread("/my/user/directory/Documents/8by8m.png");
using OpenCV 3.4.3, and with my attempts to use the copy of the image in the project directory the Mat has been coming up empty.
I try to use Xcode (v.7.3.1) for my C++ project (build system - make), but the experience is quite poor (and it was always like that since old versions like v4 when I started using it) - code completion doesn't work, color syntaxing works oddly (no coloring sometimes, or partially colored code), no "jump-to-definition" functionality, can't switch b/w header/source files with shortcuts. Basically, it's just a text editor where I have to use "Find" and Cmd+Shift+O all the time.
Is this intentional and Xcode will never get any proper support for C++ projects with external build system (make) or am I misconfiguring my project? How can I re-index files in the project? How can I make code completion work?
Thanks,
I believe there is a way to use Xcode with makefiles by adding an external build target, file->new->target->External Build System.
This is an older tutorial but the steps may be worth looking through: http://web.ist.utl.pt/jose.alberto.coelho/mac/MakefilesXcode.pdf
I've never had a problem with the syntax highlighting, but I remember the refactoring support being limited for C++ in some ways.
So, I ended up using this workaround: even though, I use external build system, I create Console Application project in Xcode and choose C++ language in settings. Then, I simply add my source files to the project (just drag folders from the Finder window) and then manually create project targets of type External Build System as I need. I don't use default target and don't use generated main.cpp file at all.
My files get indexed with no problems. I'm also able to debug code as I used to.
I still think Xcode developers should review indexing process for the projects with external build system...
Thanks for all the insights though!
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 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 have the following Problem.
I started to use the boost library version 1.40, for unit testing.
Since some other people working on the project and not all of them are using eclipse, the program has to be compilable with a makefile. So we used cmake to generate one.
The good thing is, the test is building and working perfectly fine.
But the problem is, when using eclipse (created a c++ makefile project), it complains about several syntax errors (in the sourcecode view).
Something like:
BOOST_AUTO_TEST_CASE( my_test )
{ some code }
will be detected as a syntax error by eclipse. It is really annoying having all these error messages in the IDE. Since after the first line nearly every line in the some code block is marked as having syntax errors as well.
So here is what i tried already:
I added `/usr/include/boost/` to the GNU C++ path options. (properties->C/C++ General->Path and Symbols->Path). This works normally for other external libs that are included by FindPkgConfig in the cmake file. So that the auto completion in eclipse can find the correct classes and function names.
Same way included `/usr/include/boost/test/` directly.
Adding `/usr/lib/libboost_unit_test_framework.so.1.40.0` to the Libraries list.
Adding `/usr/lib` to the Library Paths.
So anyone has a hint how to teach eclipse that the syntax of the boost Macros is correct??
Update:
I forgot:
System is Linux and Eclipse Version is 3.6.1, CDT Version is:
Version: 1.0.0.201009141542
Build id: 201009141542
I don't have a solution but maybe a hint.
I had a similar setup and it worked perfectly until...
the only relevant change I remember is that I changed the name of a test suite.
So (probably) after that, the syntax highlighting went crazy.
I tried indexing and refreshing but it didn't help.
I can't even see the macro expansion because the syntax error prevents it from popping up.
My guess is — still — some indexing issue, because it worked before and I didn't change any include paths. It compiles without problems, but it's urinating these yellow syntax error markers all over the document, which is really, really annoying.
However, it's probably not a path issue because it worked for me before.
I just did this myself using Eclipse Helios, and it does indeed work for me...
Shouldnt you add /usr/include and not /usr/include/boost, since boost is part of the include path used in your program?
For example <boost/unit_test.hpp> is simply <unit_test.hpp> if you include the boost folder aswell..
This is what I have added under GNU c++ include directories:
/usr/local/include //this is where I store the boost folder
/usr/include/c++/4.5.2 //This was needed since not even <map>, <vector> etc would resolve in eclipse.
Intellisense and autocompletion for C++ are pretty much impossible to get right in all cases. If the many macros used in Boost.Test confuse Eclipse, then perhaps you should find a cleaner unit test library. I can recommend Catch, which has a cleaner and friendlier syntax, is header-only so it's much easier to set up, and doesn't rely on macros. It is under active development by another SO user.
I had this problem as well (but on a Mac system). Once I added the boost path to GNU C++ path options, I restarted my operating system and Eclipse doesn't tag BOOST_AUTO_TEST_SUITE as an error any more.