When parsing C sources, Eclipse seems to ignore #includes with respect to defined macros. This is bad when it comes to highlighting and also sometimes auto completion. As an example, assume the following two header files:
bar.h:
#define BAZ 1
foo.h:
#include "bar.h" //<-- Jumping from here leads to the correct file
#ifdef BAZ
int baz() { //
return BAZ; // this section will be grayed out
} //
#else
int baz() {
return 42;
}
#endif
int foo() {
return baz(); // jumping from here will go to the second(42) function
}
So far I have tried to change the Discovery options/profile for the project as well as switching to "Use active build configuration" for the indexer in the general preferences.
The project is a relatively small (yet riddled with macros) C/C++ project using an external builder (autotools/make).
Additional Notes:
I figured out that part of the problem is that I was referencing header files from a different project that were installed to a separate directory using Makefiles. I switched the include directory from the installed, to the project internal /include directory. Now when I build the other project, it seems to resolve the macros in those header files. This is not exactly pretty, but it kind of works for me.
Verify you have all relevant options checked in:
Preferences-> C/C++ -> Indexer -> Index unused headers (...)
Related
I am just starting out with Segger Embedded Studio. Right now trying to call a function of a included header file. The file seems to be included since it shows up in the dependencies. For now I simply included the header and C-File in the project directory.
The included Header- and C-Files are simply:
//##### Header-File ######
#ifndef TEST_H_
#define TEST_H_
void printText(void);
#endif //TEST_H_
and:
//###### C-File #########
#include <test.h>
#include <stdio.h>
#include <stdlib.h>
void printText(void)
{
printf("Hello");
}
But when I try to call the printText Function in my main I get the error:
"Undefined Symbol: printText".
Why is the function not recognized?
"Undefined symbol" is a linker error. You are not linking the object code containing the definition of printText().
It is not an issue with the header file; including a header file does not cause the associated code to be linked - that is just the declaration so the compiler knows what the interface looks like. It is the linker than combines the separately compiled object code to form a program. You have not told the linker to use the object code containing printText(), and you have not told your IDE project to compile it to generate that object code.
The project tree clearly shows that only main.c is included in your project; you need to add the C file containing printText() too.
The concept of separate compilation and linking is what you need to grasp here.
Thank you Clifford for your answer. You are right I had some miss-conceptions about which files will be linked while building the project. In the special case of segger embedded studio there are, as I know by now, two ways to reference extern files.
Adding the files to the sources files folder is straight forward, but must be done separately for each project you want to use the respective files.
For frequently used files it is beneficial to create a dedicated library solution. Such a library can then be imported to any solution by choosing "add existing project". This will add all files of the library to your current solution (and show them in the project-tree). Now click the tab project -> dependencies. Your library should show up here. By acitivating the check box the linker will compile the referenced project upon builing your solution, allowing for the usage of your library functions.
Adding and linking library-project to a current solution
I'm working on a project which requires to develop the firmware for several esp32. All the microcontrollers share a common code that takes care of wifi and mqtt, however they all have a different behavior, which is defined in a specific component. The structure of my project is something like this:
- CMakeLists.txt
- Makefile
- sdkconfig
- main
- CMakeLists.txt
- main.c
- components
- wifi_fsm
- wifi_fsm.h
- wifi_fsm.c
- CMakeLists.txt
- mqtt_fsm
- mqtt_fsm.h
- mqtt_fsm.c
- CMakeLists.txt
- entity_1
- entity_1.h
- entity_1.c
- CMakeLists.txt
- entity2
- entity2.h
- entity2.c
- CMakeLists.txt
...
Each entity defines some functions with standard names, which implement specific logic for the entity itself and which are called within the shared code (main, wifi_fsm, mqtt_fsm).
void init_entity(); // called in main.c
void http_get(char *buf); // called in wifi_fsm
void http_put(char *buf);
void mqtt_msg_read(char *buf); // called in mqtt_fsm
void mqtt_msg_write(char *buf);
My idea was to have a conditional statement to include at will a specific behavior, so that depending on the entity included, the compiler would link the calls to the functions above to those found in the specific included library. Therefore, at the beginning of main.c I just added the following lines with the goal of having to change the only defined pre-processor symbol to compile for different enity behaviors.
#define ENTITY_1
#ifdef ENTITY_1
#include "entity_1.h"
#elif defined ENTITY_2
#include "entity_2.h"
#elif ...
#endif
#include "wifi_fsm.h"
#include "mqtt_fsm.h"
void app_main(void)
{
while(1){
...
}
}
On the one hand the compiler apparently works fine, giving successful compilation without errors or warnings, meaning that the include chain works correctlty otherwise a duplicate name error for the standard functions would be thrown. On the other hand, it always links against the first entity in alphabetical order, executing for instance the code included in the init_entity() of the component entity_1. If I rename the standard functions in entity_1, then it links against entity_2.
I can potentially use pointers to standard calls to be linked to specific functions in each entity if the approach above is wrong, but I would like to understand first what is wrong in my approach.
EDIT in response to Bodo's request (content of the CMakeFile.txt)
Project:
cmake_minimum_required(VERSION 3.5)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(proj)
Main:
set(COMPONENT_REQUIRES )
set(COMPONENT_PRIV_REQUIRES )
set(COMPONENT_SRCS "main.c")
set(COMPONENT_ADD_INCLUDEDIRS "")
register_component()
Component:
set(COMPONENT_SRCDIRS "src")
set(COMPONENT_ADD_INCLUDEDIRS "include")
set(COMPONENT_REQUIRES log freertos driver nvs_flash esp_http_server mqtt)
register_component()
This answer is based on guessing because I don't have enough information. For the same reason it is incomplete in some parts or may not fully match the use case of the question.
The details about how the project will be built seems to be hidden in a cmake include file like project.cmake or nested include files.
My guess is that the build system creates libraries from the source code of every individual component and then links the main object file with the libraries. In this case, the linker will find a symbol like init_entity in the first library that fulfills the dependency. This means the library (=component) listed first in the linker command line will be used.
If the linker command line would explicitly list the object files entity_1.o and entity_2.o, I would expect an error message about a duplicate symbol init_entity.
I can propose two ways to solve the problem:
Make sure only the selected entity is used to build the program.
Make the identifier names unique in all entities and use preprocessor macros to choose the right one depending on the selected entity.
For the first approach you can use conditionals in CMakeLists.txt. See https://stackoverflow.com/a/15212881/10622916 for an example. Maybe the register_component() is responsible for adding the component to the build. In this case you could wrap this in a condition.
BUT modifying the CMakeLists.txt might be wrong if the files are generated automatically.
For the second approach you should rename the identifiers in the entities to make them unique. The corresponding header files can define a macro to replace the common name intended for the identifier with the specific identifier of the selected entity.
In the code that uses the selected entity you will always use the common name, not the individual names.
Example:
entity_1.c:
#include "entity_1.h"
void init_entity_1(void)
{
}
entity_2.c:
#include "entity_2.h"
void init_entity_2(void)
{
}
entity_1.h:
void init_entity_1(void);
// This replaces the token/identifier "init_entity" with "init_entity_1" in subsequent source lines
#define init_entity init_entity_1
// or depending on the parameter list something like
// #define init_entity() init_entity_1()
// #define init_entity(x,y,z) init_entity_1(y,x,z)
entity_2.h:
void init_entity_2(void);
#define init_entity init_entity_2
main.c
#define ENTITY_1
#ifdef ENTITY_1
#include "entity_1.h"
#elif defined ENTITY_2
#include "entity_2.h"
#elif ...
#endif
void some_function(void)
{
init_entity();
}
In this example case with #define ENTITY_1, the preprocessor will change some_function to
void some_function(void)
{
init_entity_1();
}
before the compilation step and the linker will use init_entity_1 from entity_1.c. An optimizing linker may then omit the object file entity_2.o or the corresponding library because it is unused.
I am developing a C application, and using Eclipse CDT IDE, which I find great. The project uses Glib,Gtk,and GStreamer , so whenever I use some of their features in a file, I need to include:
#include <glib.h>
#include <gtk/gtk.h>
#include <gst/gst.h>
The code compiles without any error, since the PATH variable to search those headers is set correctly in a CMakeLists.txt.
However, while working on the project, I found annoying errors highlighting in my code, regarding type definitions like gchar or GValue or GTKApplication; the error outlined is "symbol **** could not be resolved". These definitions are inside a header file that my Eclipse IDE cannot find (included by glib.h), if not at compile time (indeed the program compiles correctly). Instead, the type GError , defined in gst.h , is not highlighted as an error by the pre-compiler.
I would like then that my Eclipse IDE could search on nested headers (#include inside an #inlcude inside...) to find those type definition, in order so to not have those annoying errors highlighting. How can I do so? I would not like to have to include directly all files where the type definitions are done.
EDIT: As Jonah Graham outlined, the problem is not beacuse Eclispe does a "single-step research" on the headers, since it inspects includes inside other includes like any other IDE. It is a CMake bug with c and Eclipse
Thanks in advance.
The problem you are facing is a CMake bug*. CMake adds __cplusplus into the defined symbols unconditionally, which means that glib headers are not parsed properly when in C mode. You can see this clearly by opening gmacros.h around the definition for G_BEGIN_DECLS:
Because CMake told CDT __cplusplus is defined, it thinks G_BEGIN_DECLS is also defined, which makes code like this from gtypes.h parse incorrectly:
G_BEGIN_DECLS
/* Provide type definitions for commonly used types.
* These are useful because a "gint8" can be adjusted
* to be 1 byte (8 bits) on all platforms. Similarly and
* more importantly, "gint32" can be adjusted to be
* 4 bytes (32 bits) on all platforms.
*/
typedef char gchar;
...
Of course with no gchar defined, everything else is going to go badly.
Luckily there is a quick workaround until the problem is resolved in CMake, remove __cplusplus from the info in CDT.
Open Project Properties
C/C++ Include Paths and Symbols
Remove __cplusplus from the list and press OK
(sometimes necessary) Right-click on project -> Index -> Rebuild
* There may be some other workarounds if you know CMake better. The bug says also it will be fixed for the next release of CMake.
Is there a way to make the Eclipse editor presume that a specific C header file has already been included, without having to #include it explicitly?
For example, how can we achieve:
#include "common_type_defs.h"
#include "special_type_defs.h" // Don't want to have to mention this header file
main()
{
common_type var1;
special_type var2;
.....
}
by writing only:
#include "common_type_def.h"
main()
{
common_type var1;
special_type var2; // Eclipse editor: "Symbol 'special_type' could not be resolved"
.....
}
without getting the Eclipse editor annotation error: "Symbol 'special_type' could not be resolved".
The reason is, the project uses a custom scripted build system. The special header files are added automatically by the build system, selected from different libraries. So the build succeeds.
I have added the special header folder to the include paths of the project. This allows me to hit [F3] and jump to the definition of "special_type". It is just that the editor flags an error.
I do not want to silence the error because I want to catch real errors.
Any suggestions?
Go to:
Project properties → C/C++ General → Preprocessor Include Paths, Macros etc. → Entries → GNU C
Select CDT User Setting Entries and than click Add button. Select Include File and enter your preprocessor pre-include file here.
Apply and rebuild indexer.
I am using Oxygen.1a Release (4.7.1a)
Do additional define in your build system and then:
#ifndef CUSTOMBUILDER
#include "special_type_defs.h" // Don't want to have to mention this header file
#endif
I ended up creating different "build configurations", for each build option of the build system. There I can add the background header files, as required.
One disadvantage is that I must maintain the different build configurations to mirror the build system: when new header files are added to the build system, the same files must also be added to the eclipse build configuration. So this solution will be unsuitable for big team projects where multiple people frequently change the included files because you could easily miss a file change or two. But it works well for small teams and infrequent changes.
This is my java file for which i wanted to generate a header file using javah for an android opencv application.
package com.hosa;
public class edgejava{
static{
System.loadLibrary("edgejava");
}
public native int main(``);
}
The generated header file is as below.
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class com_hosa_edgejava */
#ifndef _Included_com_hosa_edgejava
#define _Included_com_hosa_edgejava
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: com_hosa_edgejava
* Method: main
* Signature: ()I
*/
JNIEXPORT jint JNICALL Java_com_hosa_edgejava_main
(JNIEnv *, jobject);
#ifdef __cplusplus
}
#endif
#endif
the eclipse is pointing out that inclusion of jni.h in the header file is unresolved.
what are the steps to be taken to solve this????
regards,
srijith
I am having issues with this as well so for anyone that stumbles on this ...
I solved the JNI issue from eclipse - you may have already done step 1 or something similar
File -> New -> Other-> C++ > Convert to C++ Project
RIght Click on Project Head -> Properties -> C++ General -> Paths And Symbols
Add a path similar to this under GNU and GNUC++ Language Entries
/NDK/Platforms/Android-9/arch-arm/usr/include
Your path will be different dependent on how you are setup, which platform number etc.
Once done then rebuild the indexes when it prompts you
Close your project, re-open it, then clean-build (or it might happen immediately)
In my case the JNI.h was then found BUT the JNIEnv etc. were still unrecognized even though they are in the JNI.h file.
Also note for anyone having this issue it wont stop you from building, you just need to close the offending files, then open and close your project to get rid of the errors (what a pain)
UPDATE: FIXED!
In edition to the Above in Indigo do the following from the menu / dialog
Window->Preferences->C/C++->Index check the "Index Unused Headers" reindex/build if necessary
You might also need to add "/NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/lib/gcc/arm-linux-androideabi/4.4.3/include" above the include I mentioned above to the language entries.
All symbols are now recognized - Hope this helps someone it was driving me nuts.
FIXED!
Add to Application.mk:
APP_STL := gnustl_shared
Go to Properties -> C/C++ General -> Preprocessor Include-> Entries -> Add -> Include Directory -> File System Path, and select the path of the includes like:
${NDK_ROOT}\platforms\android-21\arch-arm\usr\include
${NDK_ROOT}\sources\cxx-stl\gnu-libstdc++\4.8\libs\armeabi-v7a\include
${NDK_ROOT}\sources\cxx-stl\gnu-libstdc++\4.8\include
${NDK_ROOT}\toolchains\arm-linux-androideabi-4.8\prebuilt\darwin-x86_64\lib\gcc\arm-linux-androideabi\4.8\include
!!! Check "Contains system headers" checkbox for each included path. !!!
Go to Properties -> C/C++ General -> Preprocessor Include-> Providers -> Check CDT GCC Built-in Compiler Settings -> OK
Clean and rebuild your project.
I had the same problem with Android JNI.
I fixed it by pointing the project to the include path of android jni.h in the NDK source
See how to download NDK from here:
https://developer.android.com/tools/sdk/ndk/index.html
Details about the fix is here:
Android Add Native support - unresolved jni.h, android/log.h etc
In my case, I just closed and open the project, then the errors disappeared.