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.
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 am trying to implement the use of DSP in the STM32 F411RE board, but I cannot seem to include the necessary files without invoking numerous errors.
Background
I have previously had CMSIS and CMSIS-DSP working in Keil uVision, but given the code limit of 32k that puts me over the evaluation limit rather quickly. As such I have been attempting to include CMSIS-DSP into Atollic TrueStudio but this seemingly is difficult to accomplish: there is limited documentation available on the CMSIS-DSP to begin with and even less so for implementation in Atollic TrueStudio.
Some related resources can be found in the
Atollic TrueStudio User Guide
as well as
StackOverflow topic #1
and
StackOverflow topic #2
. Most other related topics I could find just refer to the use of Keil uVision or the User Guide without much further help.
Atollic TrueStudio does incorporate a in-built package manager where the base CMSIS is available for download, but it does not provide this option for the CMSIS-DSP pack.
Attempted solution
I have attempted to manually download the corresponding CMSIS package (STM32Cube_FW_F4_V1.24.0) and place the corresponding DSP package into the project file structure. This then permits the use of the DSP functions such as
#include arm_math.h or arm_rfft_fast_instance_f32 S; which can also be invoked with the use of the autocomplete functionality and as such are thus recognized by the IDE.
However, this process also invokes many errors as the included functions fail to recognize their header dependencies (such as the #include arm_math.h). I find it confusing that the main.c is able to recognize the #include arm_math.h command yet the functions included are not, but I nevertheless try to fix this by adding the CMSIS DSP to the included directories (found at 'Build properties --> C/C++ Build --> Settings --> Tool Settings --> C Compiler --> Directories`). However, this does also not remedy the issue at hand.
Code results
The function cannot find the header
However the main can find the exact same header
And the header is included in the build options -> directories
Just verified that it is also included in the 'path and symbols', which it should do automagically AFAIK once you include it in the build options:
Update
Since my OP I have made some progress, mostly via messing around with the includes, symbols and linker. I have now managed to defeat the original error (though unfortunately I have no idea how), but I have now incurred a large amount of additional errors for the startup_stm32 files.
These all appear to be bad instruction errors referring to the template files included in CMSIS (CMSIS / Device / ST / STM32F4xx / Source / Templates / ARM / ...), which somehow cannot interpret the various commands listed in these templates.
Example errors: bad instruction __heap_base
I have since figured out the issue for my project: including the CMSIS folder as available from the Github repo means that a lot of templates are present throughout the entire folder structure. When attempting to build / compile whilst these templates are still present it causes a lot of issues with invalidated types and re-defining errors.
Most of these templates are in a logical location, but some are buried quite deep down and may thus be difficult to find. I will try to make a video soon describing the process of adding CMSIS (DSP) from the github repo to your project in TrueStudio.
In the meantime, the following steps should make CMSIS and CMSIS-DSP work in your STM32 TrueStudio ProjecT:
Ensure that all templates (folders) are removed from the CMSIS folder. This may require some searching and experimenting: the particularly noxious ones are hidden in
../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/Device/ST/STM32xxxx/Source/{Templates}
whilst there are also other sets at ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Examples} and ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Projects} that I had removed for my project to compile / build succesfully.
Include all the folders that are named include in the folders. AFAIK you cannot just include the main ../Drivers folder, as includes do not appear to also include the underlying structure and it also seems to include errors for my project. Best to just include the folders manually: you can so so by right-clicking on the intended folder to include, click the option near the bottom "Add/Remove include path" and tick both boxes for release and debug before pressing 'OK' to include this folder. Repeat for the other 'include' folders.
Fish up the RTE_Components.h file located at ../STM32Cube_FW_xx_Vx/STM32xxxx-Nucleo\Templates\MDK-ARM\RTE. There are also files with this name (RTE_Components.h) available in the NN (Neural Networks) CMSIS-pack folder, do not touch those. Copy this file to any location that you have previously included (placed mine in ../Drivers/CMSIS/Include), and open it up in your IDE of choice. Add the line #define CMSIS_device_header " DEVICE_NAME.h " before any of the other statements and replace device name with your STM32 board name. For example, my RTE_Components.h file looks like
/*
* Auto generated Run-Time-Environment Component Configuration File
* *** Do not modify ! ***
* Project: 'Project'
* Target: 'STM32F410Tx_Nucleo'
*/
#define CMSIS_device_header "stm32f4xx.h" // define own board header, eg stm32f4xx.h or stm32f7xx.h
#ifndef RTE_COMPONENTS_H
#define RTE_COMPONENTS_H
#endif /* RTE_COMPONENTS_H */
Make sure that the device name for the CMSIS_device_header corresponds to the header .h
file located in ../Drivers/CMSIS/Device/ST/DEVICE_NAME/Include/DEVICE_NAME.h
Add the required symbols (right-click your project, go to properties, C/C++ General, Paths and Symbols; then go to the #Symbols tab) to define the FPU and your Cortex Core type. For me I need to add __FPU_PRESENT (either with no value or value '1') and because I have the Cortex M4 chip on the STM32F411RE I add ARM_MATH_CM4. This means that my list of Symbols looks like:
__FPU_PRESENT
__packed with value __attribute__((__packed__))
__weak with value __attribute__((weak))
-ARM_MATH_CM4
STM32F411xE
USE_HAL_DRIVER though this depends if you want to use the HAL or not
Again make sure that the necessary includes are well defined, as not including only 1 directory can lead to a large amount of errors. These can be found by going to project properties (right-click your project, option at the bottom), going to the C/C++ Build, Settings, then the Tool Settings tab, C Compiler dropdown and to the Directories option.
For my project I have the following include path's inside the project properties:
../Inc (should be by default)
../Drivers/CMSIS/Device/ST/STM32F4xx/Include (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy (should be by default)
../Drivers/CMSIS/Include (should be by default)
"${workspace_loc:/${ProjName}/Drivers/Device/ST/STM32F4xx/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core_A/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/DSP/Include}"
Hopefully this helps and works for you too!
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.
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 (...)