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.
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'm trying to write a program using flex++, however everytime I try to compile I receive the error message:
FlexLexer.h: No such file or directory
However that header is found on the include folder of flex. I don't have problems compiling lex programs for c, however for c++ with flex++ I can't seem to find a way.
I already downloaded flex various times and I don't know if there is a problem with my OS or something like that. My OS is Windows 10.
Thank you
Including should be pretty straightforward once you understand how it works.
Let's look at some different ways you can include a file:
#include "FlexLexer.h"
The quotes tell the compiler to look for the file FlexLexer.h in the same folder as the file being compiled. That is it, it won't look anywhere else.
Now if we change the quotes to brackets:
#include <FlexLexer.h>
This tells the compiler to look for FlexLexer.h in the same folder first, but then if it isn't found it will go through the list of include paths looking for it there, too.
Assuming you are using VisualStudio, there is both a system list of include paths (see Tools > Options > Projects and Solutions > VC++ Directories) and a project list of include paths (right click on the Project in the Solution Explorer, Properties > VC++ Directories). Both of these lists are traversed.
Finally, you can also add subdirectory qualifies to the include, e.g.:
#include "Win\FlexLexer.h"
or
#include <Win\FlexLexer.h>
As you might guess, it looks for the path under either the current directory in the both examples and also under the include path list in the later example. Regardless, the first time the file is found the search will stop and the compiler will use it. So be careful if there are headers will duplicate names in different libraries!
So a few hours ago I started learning c++ in codelite but I was getting frustated with, so I just got codeblocks and imported the project. But now whenever I try to compile it returns:
fatal error: imports.h: No such file or directory
This is my project hierarchy in codeblocks:
And this is what the project folder looks like:
What am I doing wrong?
I know this is years later, but I've recently seen students following what I deem is frankly bad advice such as what is given above. For those learning c++ this functionality is NOT for you. To add headers you should simply check that you are using double quotes, instead of angled brackets i.e.
#include "myheader.h"
and NOT
#include <myheader.h>
Angled brackets are meant for libraries (informally) and adding a simple header file for you basic classes does not require you to change default search directories. The problem comes when someone else tries to run your code (assuming you're doing this for uni) and their IDE isn't setup to search for a "library" (your header) where it shouldn't be. Double quotes tells the compiler the files exist in your current relative directory. This way you can keep your main, headers and header implementation in one directory. Fiddling with your IDE should only be done when necessary. KISS
You have to tell Codeblocks where to find the header files that you include. Try adding the full path to your '/Headers' in the include directories of codeblocks
Goto 'Codeblocks menu > Settings > Compiler > Search directories > Add'.
EDIT: Since your issue, however, is quite irrelevant to learning the C++ language itself, I suggest that you start with simpler programs, then move on to more complex ones. That, of course, unless you have previous experience with other programming languages
Since I haven't found any Makro for
#define 'hostname of device where compiler is located' // which is unique and not to be copied !
I have now successfully used and included
#include "myCompileEnv.h"
as a workaround with the comments above, which is located more central - above the project directories in CodeBlocks.
I am a beginner with embedded programming and am using the IAR workbench for a project of mine using STM32F4Discovery. I am trying to compile an existing code and have a few errors at a few places regarding the bit definitions like the following:
Error[Pe020]: identifier "GPIO_PIN_SET" is undefined
Now, the GPIO_PIN_SET is defined in the file stm32f4xx_gpio_hal.h and is already included in my project. In order to resolve this issue when I looked up online, I have found this solution. However, I don't have the System tab in the General Options in my IAR Workbench. I have a full version of IAR Workbench and am not sure why the System tab is missing.
I also tried defining
#define ENABLE_BIT_DEFINITIONS
as stated in this link in my main.c file but to no avail.
Trying to set
#define STM32F4XX
#define USE_STDPERIPH_DRIVER
in the main.c file or defining the symbols STM32F4XX, USE_STDPERIPH_DRIVER in the Preprocessor tab in General Options as mentioned here also didn't help.
The solution could be very simple that I am probably overlooking but am not able to figure out what could I be missing. Any help would be appreciated
Including a header file in a "project" is not enough, you should actually include it (directly or indirectly) in the source file where the declarations are to be used. It would be that simple in any halfway sane development kit, but we are stuck with ST, and they force us doing it their way.
Include the "master" header in your main.c
#include "stm32f429i_discovery.h"
this would in turn include stm32f4xx_hal.h, which includes stm32f4xx_hal_conf.h, which included stm32f4xx_hal_gpio.h if the right #defines were there.
You might not have stm32f4xx_hal_conf.h
If that's the case, then copy Drivers\STM32F4xx_HAL_Driver\Inc\stm32f4xx_hal_conf_template.h into your project, rename it to stm32f4xx_hal_conf.h. Otherwise just make sure that #define HAL_GPIO_MODULE_ENABLED is not commented out.
Set the right #defines
New versions of STM32CubeF4 have been released since the tutorial you've linked was written, and a few things have apparently changed. As of version 1.6.0, define STM32F429xx in Preprocessor Options, and forget the ones above. Yes, I've noticed that there is a version 1.7.0 now, let's hope that compatibility lasts this time.
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.