I'm newbie on using CDT and Eclipse. I want to make an STM32F10XX (Cortex-M3) aplication. I have a problem when I'm compiling the code, it always show undefined variables error. I used Eclipse setting as shown on Setting up Eclipse and Code Sourcery lite for STM32 Discovery Development.
But I make my own startup code, just using stm32_flash.ld and startup_stm32f10x_md_vl.S.
Is there any included or project setting missed?
discussionstackoverflowquestion
Try using the gnu99 flavor of C. Found in project Properties > C/C++ Build > Settings. MCU C Compiler Miscellaneous.
I'm guessing it is complaining about an untagged union. But this is a guess...
Related
I have set up an Eclipse environment (Eclipse IDE for Embedded C/C++ Developers 2022-12) for building C applications for a Raspberry Pi Pico. The Pico SDK uses CMake (cmake version 3.23.2) to create the Eclipse Makefiles.
Everything builds fine, but the C/C++ Editor is showing several symbols, coming from includes, as undefined.
I have been googling solutions, and several suggest changing the properties for include paths, but the suggested property does not exist in my project/workspace. Possible the answer was old, or for a different version of eclipse.
Again, the compile works but the C/C++ Editor marks the symbols as undefined (is that Codan?)
Is there a different include path for the editor syntax checker then the Make system? Where is that defined? Any other ideas?
The project include paths are correctly including the header files:
TL;DR:
How can I persuade Nsight that I'm using C++11?
In other words, where do I set the relevant discovery options?
Building with -std=c++11 is working, even from within Eclipse. I'm talking about the Indexer having troubles with defines.
Longer version:
C++11 functions are marked as unresolved in the Nsight editor, because the __cplusplus define is 199711L, instead of something >= 201103L.
When I made the project, in Project Properties > Build > Discovery Options the Automate discovery of Path and Symbols option was checked for every language and every Build Configuration. There was a note on the bottom of the Properties windows that said that the discovery method is deprecated, so I unchecked it for every language and for every Build Configuration.
Now, under Project Properties > General > Preprocessor Include Paths, Macros etc. there are system provided paths and defines (more precisely, provided by the Providers). In the list I can see the problematic __cplusplus. I can redefine it under the CDT User Setting Entries and indeed it will be the new value after rebuilding the Index, but then whenever I click something in the editor I get an error:
An internal error occurred during: "Notifying selection listeners".
org.eclipse.cdt.internal.core.index.composite.CompositingNotImplementedError
That route is a dead end obviously. Another option is to define the new __cplusplus in Project Properties > General > Paths and Symbols under the Symbols tab. I can see the "wrong" __cplusplus there as well. Redefining it there gives me the same error as above, after rebuilding the Index, when clicking in the editor.
Also, what the hell is the CDT Managed Build Setting Entries Provider? I don't see any options for it. Where is it configured?
When I try to use the CDT GCC Built-in Compiler Settings Provider I see a field where I can input command line arguments, but putting -std=c++11 there has no effect, as that entry doesn't produce a __cplusplus define.
Offtopic:
In other news, C++11 support is great with the CUDA Toolkit 7.0, on the command line and in the makefiles. It saddens me greatly that nVidia settled on Eclipse. Whatever I did with it, I've only encountered trouble with Eclipse. Takes me a week just to set up the IDE for a project. I hate it so much.
I experienced a similar problem with the indexer when using the native compiler; however, the cross compiler worked correctly. When using the native compiler, __cplusplus was defined as 199711L even though the C++ dialect had been set to C++11 and the index rebuilt.
The indexer can pick up the C++11 settings by going to
Project Settings->C/C++ General->Preprocessor Include Paths, Macros etc.->Providers->CDT GCC Built-in Compiler Settings
and doing:
Uncheck Use global provider shared between projects.
Add -std=c++11 to Command to get compiler specs like so:
${COMMAND} -std=c++11 ${FLAGS} ...
__cplusplus should now be correctly set.
I am working with c++ and it got type __uint128_t in the code. The code compiles fine on g++ (GCC) 4.8.3, but Eclipse/CDT always show error on "__uint128_t". The actual error message is "Type '__uint128_t' could not be resolved".
I tried several things already, including re-index, adding -std=c++11 to compiler's setting. Does anybody know how to make the error message disappear?
I am running Eclipse Luna Release (4.4.0) and CDT 8.4.0.
Eclipse will be able to correctly "parse" this type only if it's defined in some header of your toolchain. If it is a builtin type in compiler (just like "int", "char" and so on) - and I guess it is - then Eclipse would need to have special code to handle that type. So unless someone implements handling of this token in Eclipse, your only option is to disable this particular code analysis check for the files that use this type...
unchecking "Use global provider shared between projects" and adding -std=c++11 to the command line for the compiler specified in the "CDT GCC Built-in Compiler Settings", which can be found by opening project properties and going to "C/C++ General", "Preprocessor Include Paths", "Providers" tab.
then rebuilding the index: right-click the project, "Index", "Rebuild".
for detail please refer to the answer by davmac in post: Type 'uint32_t' could not be resolved
I had similar difficulties with Eclipse Oxygen.3 (with CDT 9.4 on Debian 7.10 64-bit, and GCC 4.7.2). I tried everything mentioned on StackOverflow as of March 30, 2018 to no avail.
Several headers in my project were being included by multiple source files. These headers were protected by #ifdef guards, but Eclipse CDT's CODAN code analysis system didn't seem to permit these guarded headers to apply to more than one .cpp source file. So numerous types and functions which returned those types were not recognized.
But after setting Window > Preferences > C/C++ > Indexer > Index all header variants, and then Rebuilding the index for the project, subsequent code analysis runs succeeded.
See a related answer from me if trying to utilize workspace-level settings.
I just install CDT plugin in Eclipse. When i start a project by click New menu in Eclipse, it shows lots of C/C++ project type:
such as: Executable/Excetuable(XL UPC)/Shared Library/Shared Library(XL UPC)....
What's different between them?
These are essentially "presets" - they have slightly different default build settings. E.g. shared library will pass the linker settings to emit .so instead of executable, XL UPC projects use compiler different then GCC by default, etc.
These settings can be changed after the project is created - but it may require a good understanding of CDT.
I am now using eclipse to develop driver and daemon on android platform in C code with a pandaboard, and I want to use eclipse plus CDT as an edit and browse tool.
I have imported android-source code into eclipse as a makefile project, and processing with indexer.
My problem is, since there are lots of head files for different archetecture(x86, arm, etc) like etc, etc. Eclipse reports an error like "unresolved inclusion xxx" because there are too much candidates of those files. Can eclipse analysis makefile and select the correct path like compiler if I specify a variable or identifier to notify eclipse just like a makefile option?
Can anyone help me, please?
Thanks,
-Yunfei
For your driver work checkout:
http://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Linux_kernel_source
In general when working with a Makefile project you need to give Eclipse a hand so it knows where to find the includes and which preprocessor symbols are defined.
Right click on your project. Select properties -> C/C++ General -> Path and symbols.
Add the most important include paths and the indexer results will become much better.