I've just started using Eclipse Indigo (coming from Galileo) and I'm getting little red bugs in the gutter for every use of size_t.
The code compiles without issue but I suspect I have to explicitly add a path to the include directories. I already have the usual suspects in there. I am cross compiling for a ColdFire processor using the Gnu tool chain so in addition to the standard include from mfg of the chip I have the includes under m68k-elf
\include
\include\c++\4.2.1
\include\c++\4.2.1\include
\include\c++\4.2.1\m68k-elf
Update
I noticed that the only place stddef.h exists for this toolchain is in a lib directory
gcc-m68k\lib\gcc\m68k-elf\4.2.1\include
I added that path, the parent path and \include-fixed from the parent but the problem still exists.
Note on testing
When testing what works and what doesn't I noticed a couple of things
Code analysis does not get re-triggered when modifying Code Analysis preference settings, I still need to make an editor change (simply adding a space works)
Turning off the Code analysis setting for Symbol is not resolved will not make the error go away.
Turning off all Syntax and Semantic Errors, triggering the analysis, going back in and turning them all back on and then turning off Symbol is not resolved keeps the error from reappearing.
Check your indexer settings under Preferences -> C/C++ -> Indexer.
There is a field there called "Filed to index up-front". Its contents should be:
cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime, sys/types.h, signal.h, cstdio
If there is something else in there, try replacing it with the above, then rebuild the index, and see if that fixes the problem.
(In particular, if what you have in that field is stdarg.h, stddef.h, sys/types.h, then I have a pretty good guess as to what went wrong. Back in Eclipse Ganymede, the value of this field was stdarg.h, stddef.h, sys/types.h. In newer versions (Galileo and Indigo), it was changed to the above. However, since this field is part of "preferences", if you exported your Ganymede preferences and imported them into Galileo/Indigo, this field was overwritten with the old Ganymede value. I was burned by this a while ago.)
To make sure to get size_t you should #include the header <cstddef>; then, it would be std::size_t, unless you also put a using namespace std or a using std::size_t.
If your toolchain can compile the code with only its default include paths and symbols, just setting Eclipse to use them should be enough. Go to C/C++ Build -> Discovery Options in the project properties, and for each language, change the Compiler invocation command from the native compiler (e.g. g++) to your cross compiler (e.g. C:\nburn\gcc-m68k\bin\g++ perhaps?). Then on the next build, the auto-discovery will run and update the so-called "built-in" paths and symbols that show up in the project's C/C++ General -> Paths and Symbols to whatever your compiler reported, and you can re-index again to make sure any warnings for the old "built-ins" are gone.
After hitting this problem and a search revealing two stack overflow questions hitting the same problem, I figured I would submit how I fixed it after it annoyed me enough to actually investigate.
I'm running Fedora and annoyingly, it has a stddef.h file in /usr/include/linux.... which is actually empty. So even though I had the compiler's stddef.h in the include path, the indexer was actually parsing this other empty file. So what needed done was:
Prefix your paths and symbols list with the compiler specific include path (in my case it was /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/) to avoid the other empty stddef.h from being parsed.
I actually had the same problem. The issue seemed to be the same like the one described in the post of fquinner, the stddef.h located in /usr/include/linux/stddef.h was empty as well. Strangely enough, the correct stddef.h was found by eclipse and even could be openened without any issues.
If you just need to fix the indexing by eclipse like me (for example when building with another build tool anyway), this indexing issue can be worked around by defining __SIZE_TYPE__ to the expected type, e.g. long unsigned int under C/C++ General -> Paths and Symbols.
Related
(NOTE: This is not a question about UNRESOLVED symbols; this is a question about INCORRECTLY RESOVLED symbols, and further, it is an indexer problem, not a build problem. Our builds are done externally and work fine; we use Eclipse as an editor only, after doing a CDT import of the project.)
We are developing a Linux shared library using Eclipse neon.3 (4.6.3) and the CDT. The library is EVENTUALLY installed to the local system, and a test app built against it, but this is not a daily occurrence. However, once installed, those need to remain where they are.
The problem is that the indexer is finding the headers in /usr/local instead of the ones in the project under development. This is exasperating, because going to a class definition winds up opening an obsolete version in a system directory. Assuming you don't notice, you then make a bunch of changes, go to save, and get a big complaint about editing a read-only file, at which point you notice the problem.
I have been able to disable everything, and try manually adding all the paths, but then the problem is that the indexer can't find the C++ Standard Library headers, and the location of those potentially varies.
What is the most compact, constrained, and correct method for ensuring the indexer will always find headers within the project before it goes poking around in /usr/local?
Constraints:
Because the library's header files are used from within both its later-linked applications and its own internal code, these header files use include directives of this form:
#include <my-lib/subsystem/ThingyDingy.h>
Toolchain-specific headers such as the C++ Standard Library should be auto-discovered.
Sadly, we use, and will need to continue to use, Boost. This means the "all header variants" option, etc., need to stay on.
Freedoms:
If there is a sane way to exclude /usr/local/my-lib from ever being indexed for any reason, that is acceptable (e.g., it does not even need to be a fallback, any use of it at all for any reason is utterly undesirable).
Heuristic magic tricks can be dumped, for all I care, so long as the Standard Library and Boost can still be found and properly indexed.
Open to all suggestions, but please, please ensure you are very familiar with Eclipse neon.3 (4.6.3) with the current CDT. We are absolutely drowning in bad suggestions from ancient versions. Additionally, we didn't use to have nearly this much trouble with this, and it is possible that it is a recent regression, though I think the question of the BEST way to do this still stands either way.
We're going insane fighting our tools. Send help. Please.
You need to change the order of the providers in Project Settings -> C/C++ General -> Preprocessor Include Paths -> Providers.
Change it so that CDT GCC Built-in Compiler Setting is below, and therefore lower priority, than project local settings.
Here is my MCVE. On my machine I have /usr/include/arpa/ftp.h which has amongst others, the following definitions:
#define PRELIM 1 /* positive preliminary */
#define TYPE_A 1 /* ASCII */
If I create a main.c with these contents:
#include <arpa/ftp.h>
#ifdef TYPE_A
#error Wrong ftp.h!
#endif
#if PRELIM != 8
#error Wrong ftp.h!
#endif
int main() {}
And my "overridden" ftp.h in my project in include/arpa/ftp.h with the same contents, except PRELIM now == 8 and TYPE_A is commented out.
And a Makefile like this:
all:
gcc main.c -o main -Iinclude
If I build without the -Iinclude, I get #error Wrong ftp.h! and with the -Iinclude everything works fine.
However, if I open my editor I get the two #ifdef blocks enabled, and therefore CDT is reporting an error.
Then go to Project Settings -> C/C++ General -> Paths and Symbols -> Includes tab and add my project's include directory to the Include directories.
Still fails, because of the order of processing.
Then go to Project Settings -> C/C++ General -> Preprocessor Include Paths -> Providers tab and move CDT GCC Built-in Compiler Settings below CDT Managed Build Settings Entries
As shown:
Here is a before and after settings change:
I am trying to use CDT to edit C++ files. However, it refuses to see the std classes like string and vector.
(I will continue to build with make outside of eclipse, for now at least. The code compiles fine. But without a definition for string etc. almost everything is shown as an error in the editor.)
I am using Luna. CDT added to a Java oriented eclipse using Help > Install New Software.
The docs just say "install the the Tool Chains and stuff happens". But having spent several hours reading up on this, I think the phrase "Tool Chain" has several different meanings depending on the sentence. These include
The compilers and linkers themselves, e.g. minggw
Extra stuff (plugin?) added to Eclipse itself so that it can use those compilers.
Configuration within Eclipse itself
My make file uses
D:\cygwin64\lib\gcc\x86_64-w64-mingw32\4.8.3\include
but sometimes CDT seems to be pointing to
D:\mingw64\include\c++\4.5.4
Which is OK, as it will have the same .h files.
I have tried fiddling with PATH (to /bin), plus the Project Properties > > Environment MINGW_HOME. The "tool chain editor" mentions MingGW and says GCC C++, but I don't know what that really means and the easy-to-use interface does not show the paths.
I also tried adding D:\cygwin64\lib\gcc\x86_64-w64-mingw32\4.8.3\include to the Paths & Symbols > Include, but that does not help.
There is also "Libraries and "Library Paths". I do not know what the difference is (both want paths) but I am guessing this is for linking, not compiling. I am also guessing that the IDE parsing of the C++ during editing is done by CDT itself, and does not rely on external compilers.
A secondary question is how does CDT determine which header files are relevant? In general that is undecidable in C, in my case my header files rely on other header files that are loaded from the containing .cpp files. I am guessing that it just ignores the #include directives and loads up every header file it comes across, hoping that there are no conflicts.
My hack is as follows, after spending too much time trying to fix it properly and no posts here.
#ifdef ECLIPSE
// Dummy declarations to help with misconfigured Eclispse
class string{};
template <typename T>
class vector{
public:
unsigned size();
void push_back(T t);
T at(unsigned idx);
};
#endif
Yes, just trick Eclipse into thinking the classes are OK. I would not call this an answer though.
Strangely the class def of string seems enough to convince eclipse that casts to char * are OK.
(I access these classes with using, so no std::)
If CDT is unable to resolve standard library includes like <string> and <vector>, this is a sign that it cannot find your compiler.
Open a Command Prompt and type g++. Is it found? If not, it means the directory containing your compiler is not in the PATH environment variable. Add this directory (likely something like D:\cygwin64\bin) to PATH (how you do this depends on your Windows version, but it's something like Computer | Properties | Advanced system settings | Environment variables), then restart Eclipse and try again.
I have been using the Indigo release for some time. I keep having a reoccuring problem with enumerations defined in include files not working. The IDE reports the symbole can't be resolved but if I copy it to the file it complains about a conflict.
This shows that it does indeed resolve it but doesn't like it for some reason.
I really hate having to code the same enumeration in many different files. Isn't that what includes are all about?
Have a look at this answer: https://stackoverflow.com/a/774914/132847
After that, you should:
check your CDT's C++ Indexer configuration. (I don't know what is the size of your project, but it might help to increase your cache's size.)
Add your headers' directories to the include path in the eclipse's project configuration (if they are not part of your project) this way:
Select “Project > Properties” from the menu. A dialog comes up. In the
tree on the left open: “C/C++ General > Paths and Symbols”.
Add your header files' path to the include path
Good luck,
Tal
I have set up Eclipse to work with OpenCV 2.1.
When I try a simple program, I get the following error:
Type 'IplImage' could not be resolved
For the following line:
IplImage* img = 0;
How can I solve this issue?
Thanks.
you sure u tried these:
Added the OpenCV core header
Included the library?
Visit http://opencv.willowgarage.com/wiki/EclipseOpenCVLinux
I had this issue for real, and not by forgetting to code or include something (code worked fine in MSVC)
I compared the .cproject files from the Hello World project and my own project, and (apart from lots of identifier numbers being different) there were a lot of additional lines. I closed the project, removed those additional lines in an editor, reopened the project, followed carrierfrequency's steps again, and it worked.
At least so I thought. All compiler errors are gone, but now I'm getting lots of linker errors, all about symbols found inside OpenCV itself. It seems the linker cannot find __exchange_and_add in cxoperations.hpp even though the GUI finds it: when I Ctrl+click on it, it takes me to bits/atomicity.h, which is properly included in cxoperations.hpp (but uses a namespace, which isn't used).
I solved this by changing the symbols __GNUC__ from 3 to 4 and __GNUC_MINOR__ from 4 to 0.
It seems Gnu C++ 3.4 doesn't use a namespace, and 4.2 and up use another include (ext/atomicity.h) which I don't have, so I arbitrarily chose 4.0.
Project Properties -> C/C++ General -> Symbols
Use ADD to change the two symbols, even though they already exist. Using Edit on them just removes them in my version of Eclispe.
I'm trying to add SVL to my project.
Without it I'm getting hundreds of errors (undefined reference...). After adding -lSVL all errors are gone, but gcc says: "cannot find -lSVL". Everything else (SDL, SDL_TTF, SDL_Mixer...) works fine.
You should inform gcc of the path where libsvl.a is installed, for example:
gcc -lsvl -L/my/path/
Also, pay attention to the case if you work under Linux ("SVL" is different from "svl").
There are two parts to adding an external library; you need to tell the compiler[1] where to find the description of the API (i.e., the header files) and you need to tell the linker where to find the implementation of the API (i.e., the library file(s)).
The list of possible locations of the headers is given by the include path, which with a traditional compiler is added to with the -I option. It takes a directory name to add; the directory is one extra place the compiler will look for header files.
The list of possible locations of the library is given by the link path. It's just like the include path, but is added to with -L. Note that you can also (at least normally) give the full path to the library directly on the command line, but this isn't particularly recommended because it tends to embed more information in the executable than is really needed.
The syntax for MSVC is recognizably similar IIRC.
If you're using an IDE, you'll probably have to set these things in the project options, but as long as you remember that you need to set both include and library paths, you'll be able to find your way through.
[1]Strictly, you're telling the preprocessor, but the preprocessor's output is virtually always directed straight into the compiler proper.