I m working on android application in which I used JNI for native c code.
I build this application on android 2.0 version and ndkr3 and it works fine.
Now when I changed the android sdk version 1.5 and api version 3 I faced problems of unable to open library libtest_demo.so.
05-13 16:54:23.603: INFO/dalvikvm(1211): Unable to dlopen(/data/data/org.abc.test_demo/lib/libtest_demo.so): Cannot find library
I put the libtest_demo.so file at the same place /data/data/org.abc.test_demo/lib/libtest_demo.so but still the same problem arises.
In my java file I called native libraries like,
System.loadLibrary("abc_jni");
System.loadLibrary("test_demo");
And from the logcat I seen both libraries used same memory address.
This is logcat output
05-13 17:56:15.732: DEBUG/dalvikvm(9897): Trying to load lib /data/data/org.abc.test_demo/lib/libabc_jni.so 0x437317f8
05-13 17:56:15.732: DEBUG/dalvikvm(9897): Added shared lib /data/data/org.abc.test_demo/lib/libabc_jni.so 0x437317f8
05-13 17:56:15.742: DEBUG/dalvikvm(9897): Trying to load lib /data/data/org.abc.test_demo/lib/libtest_demo.so 0x437317f8
05-13 17:56:15.752: INFO/dalvikvm(9897): Unable to dlopen(/data/data/org.abc.test_demo/lib/libtest_demo.so): Cannot find library
This error almost always says "Cannot find library" and there can be many reasons for this. What is annoying is that in most cases it is not the missing library but something else. Reasons I have stumbled upon:
library is missing from the directory (obviously),
library that is dynamically linked with your library is missing,
system library versions on the device/emulator that your library uses differ with those that you were linking against in compile time (missing symbols, etc.)
I have described a method that worked for me when resolving an issue with library that was working fine on emulator and was failing to load on Nexus One, maybe this will help you: http://mpigulski.blogspot.com/2010/09/debugging-dlopen-unsatisfiedlinkerror.html
Related
I have read that incremental linking and non-incremental linking should be functionally equivalent, but I have recently found a situation where this is not the case, and it's kind of baffling me. It that out that my project's build is unable to explicitly load one DLL (out of many) that contains a wxWidgets GUI element during runtime without incremental linking (/INCREMENTAL) enabled.
To give a little context, I have the following targets built by my project:
main.exe
core.dll
foo.dll
bar.dll
core.dll contains general functions that are used by all other projects. main.exe is a desktop GUI application (using wxWidgets) that explicitly loads foo.dll and bar.dll at runtime via "LoadLibraryW". "GetProcAddress" is then used to request GUI elements from within the DLLs to be displayed, which is all done asynchronously via wxEvent. This has worked as intended for the most part. However, I have found that an issue arises when the main.exe is not incrementally linked.
Specifically, when main.exe is not linked with a core.dll that was linked with /INCREMENTAL, and when my project is implicitly linked to the release build of wxWidgets (which is not incrementally linked), foo.dll crashes at runtime on allocation of a new wxPropertyGrid, or wxPropertyGridManager (have tried both). The exception is thrown within "wxmsw30u_propgrid_vc_x64_custom.dll", which is clearly the property grid DLL. Since the debug version of wxWidgets is incrementally linked and does not crash, I was unable to get further information than this.
That is to say, when using the Release DLL version of wxWidgets, my project works if and only if a core.dll is linked with /INCREMENTAL and then linked into main.exe, regardless of whether or not main.exe is linked incrementally. foo.dll can be linked with a core.dll that was linked with /INCREMENTAL:NO and still be opened correctly by main.exe so long as that condition is satisfied. There are no problems with the Debug DLL version of wxWidgets, which is built with /INCREMENTAL.
That summarizes my specific problem. Since the actual code spans several files long, I've decided to reduce this question to the fundamental problem: how could incremental linking enable what I presume to be a faulty build to run successfully? I'd like some insight into this question in particular since it is truly baffling to me.
EDIT: Specifically, I am using wxWidgets-3.0.4 on Visual Studio 2019 targeting the latest Windows 10 SDK. The machine architecture is x64. I am building the project with CMake and have experienced no such issues on Linux when linking with g++-6.3.0 and using dllopen in place of LoadLibraryW.
I am trying to run a Haskell program that depends on the Awesomium library. I've compiled it but ran into the following issue at runtime:
Roughly translated, it says that the procedure start address for awe_history_entry_get_visit_count cannot be found in the DLL file [path to my executable].
It seems like it is trying to load that symbol from my program rather than awesomium.dll.
I'm on Windows 10
I'm using stack as my build tool
The program is 32-bit (i386), because that is the only architecture Awesomium supports
I've referenced the DLLs I need in the extra-libraries field in the .cabal file
Any help or hints will be much appreciated.
I eventually managed to solve it on my own. Turns out I was trying to link to a more recent version of the Awesomium SDK.
Having downgraded to Awesomium 1.6.5 and replaced the DLLs in my build folder with the older ones, I am now able to initialise the WebCore and create WebViews.
Unfortunately, I still haven't been able to render any HTML (stuck on loading), but that's for another question...
I'm migrating an existing, working project from Eclipse to Android Studio. The code base consists of a native C++ library built with the NDK (libMylib.so), a Java class that wraps all the native code (MyClass.java), and a test harness(MyApp).
In Android Studio, I've created a stand-alone project (not just a module) that builds "MyClass", and that project has a "src/main/jniLibs" folder where I place "libMyLibrary.so".
The project builds and produces "MyClass.aar", which contains all of its dependencies -- including those .so files.
My test app imports this .aar file as a new dependency "module". It builds and deploys to a device, but encounters a runtime exception when trying to call a native method contained in the .so file.
Trying to load lib /data/data/com.mycompany.webview/lib/libMylib.so 0x4131cd18
Added shared lib /data/data/com.mycompany.webview/lib/libMylib.so 0x4131cd18
nativeCalls.cpp﹕ JNI_OnLoad() called successfully.
No implementation found for native Lcom/mycompany/Mylib/MyClass;.nativeInit
Shutting down VM
The debug statement printed in "JNI_OnLoad()" is mine, so I know the correct .so is being loaded without issue. But then something goes wrong with the call to 'nativeInit()'.
What sorts of things could cause this kind of failure?
Thanks.
1) What value does JNI_OnLoad() return? In the code that I have it is JNI_VERSION_1_6.
2) Are the function names correct?
cd bin/classes
javah com.example.MyClass com.example.OneMoreClass
This will generate the correct C/C++ headers for your native functions.
I have a question regarding VC++ 5.0.
For a dialog-based project I am writing, I have linked it to a particular dynamic link library called File32.dll by adding the corresponding .lib file to my project debug folder as you do.
I also linked to this library in the Project Settings. This library contains functions specific to a particular application which I need to access. All of the necessary header files have been included and the project builds without errors or warnings.
The problem is that once I try to debug and run the dialog, an error appears:
The program can't start because OUTPUT.dll is missing from your
computer.Try reinstalling the program to fix this problem.
OUTPUT.dll is a library I am not linking to for this project. And when I add this particular .dll to my debug folder, the same error appears with a different .dll (SYSINT32.dll).
No matter how much I add these dlls to my debug folder, the error message reappears with a new dll. Bare in mind, the project debugged and ran successfully before I linked to File32.lib. So I feel that the problem lies with File32.lib. Any ideas on what might be happening with the linker?
Use Dependency Walker to open your File32.dll. It will show all DLLs this one (statically) depends on. It will also highlight the missing ones.
As for VC++ 5.0 ... I feel the need to comment ...
Visual C++ 5.0, which included MFC 4.21 and was released 1997-04-28 (...)
that's an amazing 18 years :-)
I was using powervr sdk gles 2 libs in linux in gamekit/ogre for building an application. I get the error
"dlopen tries:libGL.so" after which application crashes.
I tried debugging using DDD etc but couldnt isolate much.
How do I fix this in linux(Ubuntu 10.10)?
Does linux refer to some default in built libs while running dlopen?
A library name like libGL.so is only used for linking at compile time. When run-time linking, you should be using the SONAME; something like libGL.so.1. If that library has any dependencies, they must also be available. Try running 'ldd /path/to/libGL.so.1' and see if there are any missing libraries. Also, make sure that you're pointing to the correct libGL; there could be a few versions on your system, each optimized for different graphics cards.