I found that rand() function from bionic does't work without including stdlib.h
extern int rand(void);
static void foo()
{
int a = rand();
}
int main()
{
foo()
return 0;
}
Results for glibc:
Compilation successful
Results for bionic:
Compilation unsuccessful
error: undefined reference to 'rand'
In bionic sources we have following implementation:
static __inline__ int rand(void) {
return (int)lrand48();
}
Why it works for glibc but not for bionic
glibc's rand() is a "normal" function located in a library. I suspect you're getting a warning about the symbol not being defined from the compiler (which cannot find it), but since the function exists in a library, the link stage can still find and link to it.
bionic's rand() is a static inline in your header file, that means it's not even defined unless the header file is included. Since the compiler cannot find it without the include and it does not exist in any library that the linker can resolve it from, compilation will fail at the linking stage.
You will get the answer if you just compare bionic and glibc sources of rand function: https://github.com/android/platform_bionic/blob/master/libc/include/stdlib.h and
http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/rand.c;hb=glibc-2.15#l26
You can see that in bionic library it inlined in header file so without .h file you can't use it.And in glibc it is separated like most of the functions. The reason is obvious I think - bionic library was developed specially for use in embedded and mobile devices with memory and speed limits, so less code and inline optimizations is useful.
Related
I need to create a .so Android shared library for a project, and I need to use functions from a C++ static library (.lib). The .so library is meant to be used just as a bridge, so I can use functions from my static library in Android apps and games. I've created a C++ cross-platform Android project in Visual Studio 2017 (also testing it in VS2019), included the header file for the static library and the library itself, and everything is theoretically configured and linked.
The current library I'm using is a simple static library for tests that has just a single function:
namespace StaticLibrary
{
extern "C" void Func()
{
// something
}
}
The file for the Android looks something like this:
#include "StaticLibraryHeader.h"
extern "C"
{
// ...
void StaticLibFunc()
{
StaticLibrary::Func();
}
}
When I try to compile the project, the compiler says:
C:\\Microsoft\AndroidNDK64\android-ndk-r16b\toolchains\x86_64-4.9\prebuilt\windows-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin\ld: error: F:\Android_IOS_libs\MobileLibraries2019\Build\x64\Debug\libStaticLibTest_x64_Debug.lib: bad extended name index at 778
and:
undefined reference to 'Func'
I can get rid of this second error by using the --whole-archive option of the linker but then this new error shows up, along with the first one:
C:\\Microsoft\AndroidNDK64\android-ndk-r16b\toolchains\x86_64-4.9\prebuilt\windows-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin\ld: fatal error: F:\Android_IOS_libs\MobileLibraries2019\Build\x64\Debug\libStaticLibTest_x64_Debug.lib: attempt to map 60 bytes at offset 6324 exceeds size of file; the file may be corrupt
I've also used Google Lib2A ( https://code.google.com/archive/p/lib2a/ ) to create a .a file, but then the following error happens:
C:\\Microsoft\AndroidNDK64\android-ndk-r16b\toolchains\x86_64-4.9\prebuilt\windows-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin\ld: error: F:\Android_IOS_libs\MobileLibraries2019\Krilloud_Android\lib\x64\libStaticLibTestDLL_x64_Debug.a: member at 192 is not an ELF object
C:\\Microsoft\AndroidNDK64\android-ndk-r16b\toolchains\x86_64-4.9\prebuilt\windows-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin\ld: error: F:\Android_IOS_libs\MobileLibraries2019\Krilloud_Android\lib\x64\libStaticLibTestDLL_x64_Debug.a: member at 870 is not an ELF object
C:\\Microsoft\AndroidNDK64\android-ndk-r16b\toolchains\x86_64-4.9\prebuilt\windows-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin\ld: error: F:\Android_IOS_libs\MobileLibraries2019\Krilloud_Android\lib\x64\libStaticLibTestDLL_x64_Debug.a: member at 1656 is not an ELF object
I'm not an Android/Java developer, so I'm lost here. How do I properly link and use my static library in a .so project? Can it be done using Visual Studio or do I really need to install Android Studio for this? I will also need to create the same thing for iOS, so I was hoping to have both projects in a Visual Studio solution.
Android/NDK project, worked with NDK versions all the way up to r8c. Under 8d and 8e, I get a compilation error message on the armeabi-v7a build:
Compile++ thumb : myproject <= MyFile.cpp
C:\cygwin\tmp\ccFXOc2F.s: Assembler messages:
C:\cygwin\tmp\ccFXOc2F.s:1935: Error: can't resolve `.data.rel.ro.local' {.data.rel.ro.local section} - `.LPIC44' {*UND* section}
The armeabi, MIPS, and x86 builds for the same project are successful.
It's reliably popping up on the same file. The file is nothing special - vanilla C++, it compiles and works on numerous other platforms (iOS, Windows, NDK r8c to name some). No STL. It does define a healthy amount of string constants though (AKA initialized read/only data). What could be going on?
Already tried a full rebuild, even deleted the obj folder altogether.
The C++ flags are:
LOCAL_CPPFLAGS := -fshort-wchar -fsigned-char -Wno-psabi
I know NDK comes with several versions of GCC; might a toolchain change help? How exactly?
Surely looks like a compiler bug to me. It's related to indexed access to a large chunk of static const data. When I've slightly reformulated a perfectly innocent statement, the error message went away.
Used to be:
//In global scope
static const LPCWSTR Comments[] = {L"A lot of strings here", L"String 2", L"String 3" /* and many more */ }:
void SomeMethod()
{
DoSomething(Comments[i]); //That was the offending line - commenting it out would get rid the error
}
Replaced with:
void SomeMethod()
{
static LPCWSTR pComments = 0;
if(!pComments)
pComments = Comments;
DoSomething(pComments[i]); //Now it works.
}
Ooky, spooky stuff.
I am using Android NDKr8 and by extension gcc to compile some library code that is shared across multiple platforms including some embedded ones. This code uses segments to put a bunch of elements into a contiguous memory space. The compile is generating a "error: variable_name causes a section type conflict".
We use a macro to declare the segment attribute:
# define DB_SEGMENT __attribute__ ((__section__ ("DBSegment")))
The above variable_name is declared as follows:
dbStruct const variable_name[] DB_SEGMENT = {
{conststringvalue0, sizeof(conststringvalue0)},
…more like this
};
dbStruct is
typedef struct dbStruct
{
const char * const address;
const UINT16 stringSize;
} dbStruct;
conststringvalue0 is declared like so:
const char conststringvalue0[] DB_SEGMENT = "some string value";
This same code compiles in Xcode using its default compiler with only a small modification in the declaration of the DB_SEGMENT macro. This is deeper C than I am used to so any help would be appreciated. Google has some references to the error but the fix for it is not clear. Is there a better strategy for setting up a specific contiguous memory section?
In response to a comment, here is the only difference fromthe correctly compiling version on XCode:
#define DB_SEGMENT __attribute__ ((section ("DBSegment,DBSection")))
I got the same problem. And my situation is I put the code and variables in the same section. After I put the variable in a different section, the problem dismissed. Hope this helps.
"# define DB_SEGMENT attribute ((section ("DBSegment")))"
I am seeing a space between # and define which is not correct.
Remove that space and try compiling.
I have a core project which I'm building as a shared library. In one of the headers, I've defined a simple class shown below:
typedef pthread_mutex_t Mutex;
class CORE_API AutoLock
{
public:
AutoLock(Mutex& m);
~AutoLock();
private:
AutoLock();
AutoLock(const AutoLock&);
AutoLock& operator=(const AutoLock&);
Mutex m_Mutex;
};
where CORE_API is defined as:
#ifdef CORE_DLL
#define CORE_API __attribute__ ((dllexport))
#else
#define CORE_API __attribute__ ((dllimport))
#endif
In the Android.mk for core, I've defined CORE_DLL under LOCAL_CFLAGS. However, when building, I get the warning:
warning: 'dllimporot' attribute directive ignored
When ndk-build gets to the other project where I want to use the AutoLock class, I get the error:
error: 'AutoLock::AutoLock()' is private
error: within this context
Why would the compiler ignore the dllexport attribute? I would hope that once that's fixed, my other project should build and be able to use the AutoLock class without any problems.
Shared libraries are created differently on Android (Linux) than with Windows.
In Windows you have the special dllimport and dllexport directives but not on Android (Linux).
When using your shared library, you should just compile with -lYourLibraryName
This might help you: http://www.adp-gmbh.ch/cpp/gcc/create_lib.html
Have a look at the sample code available in the android-ndk, specially the Android.mk file this might solve your problem.
I'm trying to use the NDK with C++ and can't seem to get the method naming convention correct. my native method is as follows:
extern "C" {
JNIEXPORT void JNICALL Java_com_test_jnitest_SurfaceRenderer_drawFromJni
(JNIEnv* env, jclass c)
{
//
}
}
with a header wrapped in extern "C" {} aslo.
Everything compiles fine, creates a .so file and copies to the libs folder under my project, but when I debug and run in Eclipse I keep getting a log cat message that of "no implementation found for native...". Is there something i'm missing as all the NDK examples are in C?
Thanks.
There are a couple of things that can lead to "no implementation found". One is getting the function prototype name wrong, another is failing to load the .so at all. Are you sure that System.loadLibrary() is being called before the method is used?
If you don't have a JNI_OnLoad function defined, you may want to create one and have it spit out a log message just to verify that the lib is getting pulled in successfully.
You already dodged the most common problem -- forgetting to use extern "C" -- so it's either the above or some slight misspelling. What does the Java declaration look like?
An additional cause for this error: your undecorated native method name must not contain an underscore!
For example, I wanted to export a C function named AudioCapture_Ping(). Here is my export declaration in C:
JNI_EXPORT int Java_com_obsidian_mobilehashhost_MainActivity_AudioCapture_Ping(JNIEnv *pJniEnv, jobject object); //Notice the underscore before Ping
Here was my Java class importing the function:
package com.obsidian.mobileaudiohashhost;
...
public class MainActivity extends Activity {
private native int AudioCapture_Ping(); // FAILS
...
I could not get Android to dynamically link to my native method until I removed the underscore:
JNI_EXPORT int Java_com_obsidian_mobilehashhost_MainActivity_AudioCapturePing(JNIEnv *pJniEnv, jobject object);
package com.obsidian.mobileaudiohashhost;
...
public class MainActivity extends Activity {
private native int AudioCapturePing(); // THIS WORKS!
...
I had the same problem, but to me the error was in the file Android.mk. I had it:
LOCAL_SRC_FILES := A.cpp
LOCAL_SRC_FILES := B.cpp
but should have this:
LOCAL_SRC_FILES := A.cpp
LOCAL_SRC_FILES += B.cpp
note the detail += instead :=
I hope that helps.
Called extern "C" as provided in the automatically-generated Studio example, but forgot to wrap the entire rest of the file, including following functions, in {} brackets. Only the first function worked.
An additional reason: Use LOCAL_WHOLE_STATIC_LIBRARIES instead of LOCAL_STATIC_LIBRARIES in android.mk. This stops the library from optimizing out unused API calls because the NDK cannot detect the use of the native bindings from java code.
There is a cpp example under apps in ndk:
https://github.com/android/ndk-samples/blob/master/hello-gl2/app/src/main/cpp/gl_code.cpp
Use javah (part of Java SDK). Its the tool exactly for this (generates .h header from .class file).
If your package name includes _ character, you should write 1(one) after _ character as shown below:
MainActivity.java
package com.example.testcpp_2;
native-lib.cpp
JNICALL
Java_com_example_testcpp_12_MainActivity_stringFromJNI(
I try all above solutions, but no one can solved my build error(jni java.lang.UnsatisfiedLinkError: No implementation found for...),
at last I found that I forget to add my verify.cpp source file to CMakeList.txt add_library segement(verify.cpp is auto generate by Ctrl + Enter short key, maybe other file name), hope my response can help some one.
my build environment: Gradle + CMake
I Faced the same problem, and in my case the reason was that I had underscore in package name "RFID_Test"
I renamed the Package and it worked.
Thanks user1222021
I faced the same problem twice. It happened, that the phone I tried to start the app from Android Studio used an API level that I haven't downloaded yet in Android Studio.
Upgrade Android Studio to the latest version
Download the necessary API from within Android Studio