I have C project for Android in Eclipse which is giving the error: Type '__u64' could not be resolved.
And __u64 appears as a greyed out type in the list beneath the relevant types.h file in the includes folder.
It seems that this problem is because the relevant type definition in the header file is preceded by #if defined (__GNUC__).
Fortunately the project builds OK (so is this an issue with Eclipse parser rather than Eclipse generator).
How do I get rid of the annoying error message?
EDIT . . .
Yes, the code is using __u64. It does what is required and the code works. My problem is not with the code. My problem is with Eclipse configuration.
I believe the Eclipse compiler (GNU C) sees the following (in types.h) -
#if defined(__GNUC__)
typedef typedeclaration
#endif
- passes the test, and accepts the declared data type.
But the Eclipse parser doesn't.
So how do I configure Eclipse so that the parser also passes the #if defined(__GNUC__) test and, in this instance, accepts __u64 as a legitimate data type.
I am programming stm8s and sht20 from sensirion company with I2C on the IAR. I'm using sht20 sample code: this link
I edited this sample code to my mcu. Then, for example I included i2c_hal.h to my main.c, but functions not working in my main.c file and IAR error is
ERROR LI005 no defition for I2c_Init()
Linking error
For example:
main.c
#include "stm8s.h"
#include "i2c_hal.h"
I2c_Init();
i2c_hal.h
#ifndef I2C_HAL_H
#define I2C_HAL_H
void I2c_Init ();
#endif
i2c_hal.c
#include "I2C_HAL.h"
void I2c_Init ()
{
SDA=LOW;
SCL=LOW;
SDA_CONF=LOW;
SCL_CONF=LOW;
SDA=HIGH;
SCL=HIGH;
}
I copied sht20 files to my project directory. What should I do for this error?
The header file is read by the preprocessor not the linker; if you get as far as linking, it is not a header file issue. The three basic build steps for C code are:
preprocess
compile
link
Your build is failing at the link state. The linker requires all compiled object files and any necessary libraries that constitute your application as input. In your case the most likely issue is that you have not compiled and linked i2c_hal.c (or strictly compiled i2c_hal.c and linked i2c_hal.obj). In the IAR IDE you simply explicitly add i2c_hal.c to your project along with main.c, and all should be good (all other dependencies being satisfied).
I suspect that i2c_hal.c will infact fail compilation since it is missing any declaration of SDA, SCL etc. - you probably need to include stm8s.h there also.
In general the process looks like this (this diagram actually omits pre-processing - i.e. expansion of headers, macros and conditional compilation etc. - but it was the otherwise clearest example I found; the original page does however mention the pre-processor stage, and the preprocessor is normally run automatically when you invoke the compiler in any case):
I have also the same issue with the spi. I got hal_spi_init() linking problem. To resolve the issue you need to enable the I2C in your stm32 hal drivers. In stm32xx_hal_conf.h file we have different #define modules. There you can enable the I2C module or just include the defined symbol in your IAR tool. Then Issue resolved
You need to add the C source files to the project. Header files shall not have any code or data, only the declarations of types , extern variables, macros, static inline functions and function prototypes.
I have an existing C-Project with a pre-written Makefile. I imported the whole thing as a Makefile-Project into Eclipse and it is working fine so far - meaning I can navigate through the code with eclipse and I can build it without problems.
Now I added some Compiler Symbols like NO_ASMto my makefile and updated the code at some points with the according lines of
#ifdef NO_ASM
// Code
#endif
This code is greyed out by my Code-Editor. Now I added the Symbol NO_ASM to
Properties/C/C++ General/Paths and Symbols and rebuilt the indexer - but the according code is still grey. Is there any way to solve this?
Are you sure you added it to all configurations? in all Languages?
You can Try Freshen all files option.
A temporal workaround can something like this:
#ifndef NO_ASM
#define NO_ASM
#endif
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.
I am working in existing C code which has a couple of lines with statements similar to this one:
struct collect_conn *tc = (struct collect_conn *)
((char *)c - offsetof(struct collect_conn, runicast_conn));
The struct collect_conn goes along the following lines:
struct collect_conn {
struct runicast_conn runicast_conn;
struct announcement announcement;
const struct collect_callbacks *cb;
struct ctimer t;
uint16_t rtmetric;
uint8_t forwarding;
uint8_t seqno;
};
I am using Eclipse CDT, and it marks the line with an orange squiggly line as 'syntax error'. I think it is marked as such by the CDT indexer.
However, compilation (manually in a terminal) is no problem.
This is a bit inconvenient however, since the elements on the line don't get indexed (so the call hierarchy tree isn't always correct, or the highlighting of elements, etc.)
Why does Ecipse not like the line as it is?
Eclipse CDT contains its own preprocessor/parser for analyzing your code and building an index. However, when you invoke a build CDT calls out to your system compiler, like gcc for example. There may be minor differences between the syntax accepted by the CDT parser and the syntax accepted by your compiler. When this happens the CDT parser can get confused.
On my system the offsetof macro expands into an expression that uses the __offsetof__ keyword. This keyword isn't recognized by CDT so that's why there's a syntax error. To deal with this problem the CDT parser has a macro built in to deal with __offsetof__ which looks like this:
#define __offsetof__(x) (x)
This doesn't appear to be correct, at least on my system the result is the removal of the __offsetof__ keyword from the source which still leads to a syntax error.
I was able to get rid of the syntax error by going to the Paths and Symbols property page and adding a macro for __offsetof__ which maps to 'foo'. This tricks the parser into thinking its just a call to a function it hasn't seen before, but not a syntax error.
Alternatively you can turn off syntax error reporting in the editor by going to Window > Preferences > General > Editors > Text Editors > Annotations and unchecking all the checkboxes for C/C++ Indexer Markers.
I've fixed problem in eclipse CDT with Preferences->C/C++->Language Mappings : Add
Content Type : C-header
Language : C++
Sometimes, although the code compiles with no error, eclipse CDT's real-time code analyzer shows some errors in C/C++ files (eg. 'Function xxx could not be resolved). This is because eclipse CDT uses its own preprocessor/parser for analyzing the code and building the indexes instead of the MinGW's one (or any other GNU compiler). In order to fix this globally for all eclipse projects in the workspace, follow these steps:
(In order to fix this only for a specific project, follow steps 1, 2 and 4 in menu 'Project->Preferences')
1-In menu 'Window->Preferences->C/C++->Language Mappings', add the correct mappings as shown in below: (eg. for content types: C++ Source/Header File, use GNU C++ language and so on)
2-In menu 'Window->Preferences->C/C++->Indexer', set full indexing by checking all checkboxes (but not 'Skip' ones) as shown in below:
3-In each project's specific properties, menu 'Project->Properties->C/C++ general->Indexer', Uncheck 'Enable project specific settings' as shown in below:
4-Rebuild the indexing, menu 'Project->C/C++ Index->Rebuild'.
It seems the CDT parser doesn't like the portion offsetof(struct ...).
If you declare collect_conn using a typedef the error goes away. At least for me, the following code works:
typedef struct {
struct runicast_conn runicast_conn;
struct announcement announcement;
const struct collect_callbacks *cb;
struct ctimer t;
uint16_t rtmetric;
uint8_t forwarding;
uint8_t seqno;
} collect_conn;
...
struct collect_conn *tc = (struct collect_conn *)
((char *)c - offsetof(collect_conn, runicast_conn));
If you can't change the original declaration do something like this:
typedef struct collect_conn collect_conn_t;
It might be confused, check if you have a definition of offsetof in-scope, for instance. Otherwise you might try simplifying the expression, breaking it up using e.g. a #define with the offset of, or something.
I'm thinking the compiler might provide a built-in version of offsetof, while Eclipses's compiler/code-parser might not. If so, you would need to make sure you have the definition, for Eclipse to be able to properly parse your code.
try switching the indexer to "Full c/C++ indexer (complete parse)" in Preferences->c/C++ -> indexer
Iv got the same problem. There is 2 definition of offsetof (one for C and one for C++). IMO the problem come from that
For example if i type
#ifndef __cplusplus
#endif
Eclipse will grey it. It mean __cplusplus is defined, but my project is a C
Unfortunatly i dont find a fix.
I fixed similar problem after checking the tab Error Parsers in Makefile Project in New CDT Project Wizard, removing CDT Visual C Error Parser (I am using gcc)
I ended up solving the problem like this. First I opened the project properties, then the C/C++ general->Paths and Symbols category. Under the Symbols tab I added this entry:
Symbol: offsetof(TYPE,MEMBER)
Value: ((ssize_t) &((TYPE *)0)->MEMBER)
These symbols are used by the indexer but not passed to the compiler (at least in Makefile projects, I haven't tried it in the other kind of C project), so it doesn't override GCC's built-in offsetof
I've seen Eclipse do this some times, and I use it for Java. Usually closing and opening the file again fixes it for me (resets whatever is wrong). It usually seems to be an error that WAS there but has been fixed and the "error cache" isn't updated correctly.