I start getting funny errors with NDK with fairly complex program:
#include <stdio.h>
#include <iostream>
int main( int argc, char **argv ) {
return 0;
}
>call c:\android-ndk-r9\ndk-build.cmd
"Compile++ thumb : test <= test.cpp
In file included from C:/workspace/c++11_test//jni/test.cpp:11:
In file included from c:/android-ndk-r9/sources/cxx-stl/stlport/stlport\iostream:43:
In file included from c:/android-ndk-r9/sources/cxx-stl/stlport/stlport\stl/_istream.h:31:
In file included from c:/android-ndk-r9/sources/cxx-stl/stlport/stlport\stl/_ostream.h:380:
In file included from c:/android-ndk-r9/sources/cxx-stl/stlport/stlport\stl/_ostream.c:26:
In file included from c:/android-ndk-r9/sources/cxx-stl/stlport/stlport\stl/_num_put.h:180:
In file included from c:/android-ndk-r9/sources/cxx-stl/stlport/stlport\stl/_num_put.c:26:
c:/android-ndk-r9/sources/cxx-stl/stlport/stlport\stl/_limits.h:217:48: error: non-type template argument evaluates to -2147483648, which cannot be narrowed to type 'wchar_t'
[-Wc++11-narrowing]
: public _STLP_PRIV _Integer_limits<wchar_t, WCHAR_MIN, WCHAR_MAX, -1, true>
^
c:/android-ndk-r9/platforms/android-14/arch-arm/usr/include\../include/wchar.h:76:22: note: expanded from macro 'WCHAR_MIN'
#define WCHAR_MIN INT_MIN
^
c:/android-ndk-r9/platforms/android-14/arch-arm/usr/include\sys/limits.h:69:18: note: expanded from macro 'INT_MIN'
#define INT_MIN (-0x7fffffff-1) /* min value for an int */
^
1 error generated.
make: * [C:/workspace/c++11_test//obj/local/armeabi/objs/test/test.o] Error 1
It's ndk-r9. 4.8 complie it just fine, only clang stumbles on it.
Do I need to define something to make clang work?
I've tried to Google errors, but got nothing relevant...
Obviously, I can turn it off with -Wno-c++11-narrowing, but I don't want disable narrowing checks.
And it's only shows with stlport_static, there is NO error with gnustl_static
You appear to have enabled C++11, since you are getting this warning.
STLport support for C++11 is not very good. I suspect this is the reason for your woes.
A fix requires changes to STLport, or removing the "-std=c++11" switch from the clang command-line.
IMHO, I would recommend switching to the gnustl (aka. libstdc++), unless there are other reasons that prevent you from doing so (licensing: libstdc++ is GPL3 with some significant exceptions that may or may not be valid for clang - you should determine that for yourself), legacy support, size etc.). I have had very good experiences with that.
Related
I am trying to use JNI code to print Android sensor timestamps to a file.
The timestamps are defined as int64_t.
The line to print the timestamp is:
fout<<timestamp<<std::endl;
Where fout is an open file stream in output mode.
When I try to compile, the following error results:
ambiguous overload for 'operator<<' (operand types are 'std::ofstream {aka std::basic_ofstream >}' and 'int64_t {aka long long int}') XXX.cpp /YYY/jni line ZZZ C/C++ Problem
I thought I would make an MWE for this using standard C++:
#include <iostream>
#include <cstdint>
int main(){
int64_t a;
std::cin>>a;
std::cout<<a<<std::endl;
}
But this compiles without an issue, which makes me think the problem is somehow in the way Eclipse compiles the code.
I am inside Eclipse 3.8.1. My default compiler is GCC 4.9.2.
I solved this problem by going into jni/Application.mk and using this line:
LOCAL_CPPFLAGS += -std=gnu++11
instead of this line:
LOCAL_CPPFLAGS+=-std=c++11.
Some have conjectured that the problem is due to different mappings of long long int in stlport.
I have namespace error building with ndk-build for native code in my Android app. The error sample is
C:/adt-bundle-windows-x86/ndk/sources/cxx-stl/gnu-libstdc++/4.6/include/bits
/allocator.h:54:1: error: unknown type name 'namespace'
C:/adt-bundle-windows-x86/ndk/sources/cxx-stl/gnu-libstdc++/4.6/include/bits
/allocator.h:55:1: error: expected ',' or ';' before '{' token
For OpenCV settings, my Application.mk file is
APP_STL := gnustl_static
APP_CPPFLAGS := -frtti -fexceptions
APP_ABI := armeabi
APP_PLATFORM := android-10
That means I am using gnu-libstdc++ in compiling the native code.
My jni.c has c extension. That is I receive from my third party and they prefer in .c extension as if they have to change to .cpp extension, they have to change a lot in their other libraries.
So far is OK, I did all project settings for OpenCV for native development and if I do ndk-build, I can make .so libraries.
The problem of those namespace error happened when I include OpenCV's header file #include <opencv2/contrib/detection_based_tracker.hpp> into jni.c and I got a lot of name space error. If I include that #include <opencv2/contrib/detection_based_tracker.hpp> into cpp file, no error.
My questions are
(1)Is the error is because of using .hpp file in .c file?
(2)If I have no choice and have to use that .c file, is there way around to remove that error?
Thanks
My assumption would be that the file is compiled as a "C" file instead of a "C++" file because of the extension ".c". That means you cannot use any "C++" Code in your jni.c, wike classes or namespaces. These are obviously used however in your file "detection_based_tracker.hpp" that you are using.
So the problem is not that you include a file named ".hpp", but that this file contains "C++" code wich the "C" compiler cannot handle.
One solution to this problem is to only use the "C" functions in opencv (for example "opencv2/imgproc/imgproc_c.h" instead of "opencv2/imgproc/imgproc.hpp"). However, your function "detection_based_tracker.hpp" might not have a "C" version, as far as I can see.
The other option is to add a second file "function.cpp" with the "C++" functions that use opencv. The functions from "function.cpp" can be declared in a file "functions.h" and included in your "jni.c", so you can still use opencv c++ functions. Be careful to only use C style functions then, though (no classes, namespaces, ...) in your "function.h" file, otherwise you will have the same problems as before.
I have tried to get following sample code working to know whether asynchronous programming is working in Android NDK. Though NDK has the STL <future> which gets recognized as a header, the std::async is not getting recognized are not getting recognized. The code I tried to use was the following:
#include <future>
#include <iostream>
struct Foo
{
Foo() : data(0) {}
void sum(int i) { data +=i;}
int data;
};
int main()
{
Foo foo;
auto f = std::async(&Foo::sum, &foo, 42);
f.get();
std::cout << foo.data << "\n";
}
Also all the include paths have been set to the specified folder under Properties->Paths and Symbols
Errors
Description Resource Path Location Type
invalid use of incomplete type 'std::__async_sfinae_helper<void (Foo::*)(int), void (Foo::*)(int), Foo*, int>::type {aka struct std::future<void>}' Sample.cpp /Project12/jni line 50 C/C++ Problem
Description Resource Path Location Type
declaration of 'std::__async_sfinae_helper<void (Foo::*)(int), void (Foo::*)(int), Foo*, int>::type {aka struct std::future<void>}' Project12 line 111, external location: D:\android-ndk-r8e-windows-x86_64\android-ndk-r8e\sources\cxx-stl\gnu-libstdc++\4.6\include\future C/C++ Problem
Curently Android NDK does not incorporate all of the C++11 features. Clang 3.3 compiler from NDK r9b is C++11-feature complete, however, STL and stdlib on Android are not.
To use the most recent C++11 feature set in Android use Clang 3.3 compiler from Android NDK r9b. Put this line into your Application.mk file:
NDK_TOOLCHAIN_VERSION := clang
Also, add -std=c++11 switch to the LOCAL_CPPFLAGS variable:
LOCAL_CPPFLAGS += -std=c++11
I am using Eclipse + gdbserver + ndk7. It seems that debugging through native code (called by Java ) takes ages to step through (~20sec each step), What might cause that? is this normal behaviour?
You can use logging for debugging. please look at this link.
Include log.h file into your Android NDK source file
#include <android/log.h>
Add the line below to your Android.mk make file.
LOCAL_LDLIBS := -llog
Now you can start logging, this two steps allows you to write logs in Eclipse from Android NDK. Write the line below in your Android NDK code and the log will bw appear in the Eclipse
__android_log_write(ANDROID_LOG_ERROR,"Tag","Message");
use following Flags to write logs in the column which you want.
typedef enum android_LogPriority {
ANDROID_LOG_UNKNOWN = 0,
ANDROID_LOG_DEFAULT, /* only for SetMinPriority() */
ANDROID_LOG_VERBOSE,
ANDROID_LOG_DEBUG,
ANDROID_LOG_INFO,
ANDROID_LOG_WARN,
ANDROID_LOG_ERROR,
ANDROID_LOG_FATAL,
ANDROID_LOG_SILENT, /* only for SetMinPriority(); must be last */
} android_LogPriority
For example if you want to write in Info column you must write
__android_log_write(ANDROID_LOG_INFO,"Tag","Message");
While attempting to cross-compile ICU using android-ndk-r7 in Linux, the following error occurs after configuration when I run 'make'
__/android-ndk-r7/platforms/android-8/arch-arm/usr/include/sys/types.h:124: error: 'uint64_t' does not name a type
This is triggered by the #include <sys/types.h> in icu/source/common/unicode/ptypes.h:25. It appears to be a non-icu issue in android-ndk-n7. In sys/types.h we see
#ifdef __BSD_VISIBLE
typedef unsigned char u_char;
typedef unsigned short u_short;
typedef unsigned int u_int;
typedef unsigned long u_long;
typedef uint32_t u_int32_t;
typedef uint16_t u_int16_t;
typedef uint8_t u_int8_t;
typedef uint64_t u_int64_t;
#endif
The culprint here is uint64_t, which is defined in #include <stdint.h> at the top of the sys/types.h. Here we see
#if !defined __STRICT_ANSI__ || __STDC_VERSION__ >= 199901L
# define __STDC_INT64__
#endif
...
#if defined(__STDC_INT64__)
typedef __int64_t int64_t;
typedef __uint64_t uint64_t;
#endif
If STRICT_ANSI or STDC_VERSION and therefore STDC_INT64 are never definied, including sys/types.h will throw an error since uint64_t is never defined. Any code that later calls either int64_t (happens in icu code) and uint64_t will also throw the same error. My temporary fix for this is to define STDC_INT64 at the top of icu's ptypes.h right before #include <sys/types.h>. Is this a bad idea?
The main issue is that uint64_t isn't a defined type in C versions prior to C99.
The best way to have it defined is to tell gcc which standard you'd like to use.
For c++, that's passing the -std=gnu++0x flag. For C, that's passing -std=c99
I.e. add a line something like
APP_CPPFLAGS= -std=gnu++0x
to your Application.mk file.
Alternatively, you can just hack it via your #define; I just wouldn't distribute code with such a hack as it's fragile.
-D__STDC_INT64__ allows uint64_t and int64_t to be defined in Android's stdint.h.
However, this is not the ideal fix. The error has to do with Android, stdint and -std=c++0x. See What's the difference in GCC between -std=gnu++0x and -std=c++0x and which one should be used? for further information. If you follow the train of thought, an alternate (better??) fix is to modify the icu configuration script so that it calls for gnu++0x instead of c++0x. That's probably the right thing to do.
*** 7238,7244 ****
OLD_CFLAGS="${CFLAGS}"
OLD_CXXFLAGS="${CXXFLAGS}"
CFLAGS="${CFLAGS} -std=gnu99 -D_GCC_"
! CXXFLAGS="${CXXFLAGS} -std=c++0x"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
--- 7241,7247 ----
OLD_CFLAGS="${CFLAGS}"
OLD_CXXFLAGS="${CXXFLAGS}"
CFLAGS="${CFLAGS} -std=gnu99 -D_GCC_"
! CXXFLAGS="${CXXFLAGS} -std=gnu++0x"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
***************
I have resolved this situation by adding in to icudefs.mk into CPPFLGAS an option -D__STDC_INT64__
Can you set -DU_HAVE_UINT64_T=0 ?
Update to NDK 8e it supports more things from C++11
Also your Application.mk should contains some flags look at my file
APP_STL := gnustl_static
APP_CPPFLAGS := -frtti -DCC_ENABLE_CHIPMUNK_INTEGRATION=1 -DCOCOS2D_DEBUG=1 -std=c++11 -DDEBUG=1
APP_USE_CPP0X := true
NDK_TOOLCHAIN_VERSION=4.7