I am porting an opencl application onto a Huawei honor8 phone, which comes with opencl. Also it is not rooted
When I ran my app, I got the error:
/system/vendor/lib64/egl/libGLES_mali.so" ("/vendor/lib64/egl/libGLES_mali.so") needed or dlopened by "/data/app/com.numericcal.ocl_peak-1/lib/arm64/libOpenCL.so" is not accessible for the namespace: [name="classloader-namespace", ld_library_paths="", default_library_paths="/data/app/com.numericcal.ocl_peak-1/lib/arm64:/data/app/com.numericcal.ocl_peak-1/base.apk!/lib/arm64-v8a:/.....
and the app crashes.
I actually have libGLES_mali.so placed under src/main/jniLibs/arm64-v8a along side whole bunch of other shared libs that libOpenCL.so depends on, I don't understand why this error pops up. (all the shared libs are pulled from the phone -- either from /vendor or /system directory)
Anyone have seen this before? Any good guess what I can do to fix it?
Thank you!
S Cheng
Can you use an ARM-friendly Readelf binary and then do
adb pull /app/com.numericcal.ocl_peak-1/lib/arm64/libOpenCL.so /tmp/libOpenCL.so and do : readelf -d /tmp/libOpenCL.so
And paste the result ?
Note that you might have to use a prefixed version of readelf. Something like armv8-gnueabi-readelf or similar...
Hi Myy,
I used the aach64 version of readelf and this is what I get.....not directly pointing to the mali library it seems.....
Dynamic section at offset 0x9cb8 contains 33 entries: Tag Type Name/Value 0x0000000000000003 (PLTGOT) 0xaf48 0x0000000000000002 (PLTRELSZ) 456 (bytes) 0x0000000000000017 (JMPREL) 0x2c48 0x0000000000000014 (PLTREL) RELA 0x0000000000000007 (RELA) 0x2078 0x0000000000000008 (RELASZ) 3024 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffff9 (RELACOUNT) 125 0x0000000000000006 (SYMTAB) 0x288 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000005 (STRTAB) 0x1008 0x000000000000000a (STRSZ) 2805 (bytes) 0x000000006ffffef5 (GNU_HASH) 0x1b00 0x0000000000000001 (NEEDED) Shared library: [libcutils.so] 0x0000000000000001 (NEEDED) Shared library: [liblog.so] 0x0000000000000001 (NEEDED) Shared library: [libutils.so] 0x0000000000000001 (NEEDED) Shared library: [libdl.so] 0x0000000000000001 (NEEDED) Shared library: [libc++.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so] 0x0000000000000001 (NEEDED) Shared library: [libm.so] 0x000000000000000e (SONAME) Library soname: [libOpenCL.so] 0x000000000000001a (FINI_ARRAY) 0xaca0 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x0000000000000019 (INIT_ARRAY) 0xaca8 0x000000000000001b (INIT_ARRAYSZ) 16 (bytes) 0x000000000000001e (FLAGS) BIND_NOW 0x000000006ffffffb (FLAGS_1) Flags: NOW 0x000000006ffffff0 (VERSYM) 0x1ef8 0x000000006ffffffc (VERDEF) 0x2018 0x000000006ffffffd (VERDEFNUM) 1 0x000000006ffffffe (VERNEED) 0x2034 0x000000006fffffff (VERNEEDNUM) 2 0x0000000000000000 (NULL) 0x0
Interesting...
You could try to use readelf on the other shared libraries accompanying your app.
OR
You might already have a libOpenCL.so library provided by Huawei on your system, and the libraries depending on libOpenCL actually use the system's one. Try to take a look in /system/lib and /system/vendor. Try analysing it, if you find it, and check for hard coded references, either by using readelf or by using 'strings libOpenCL.so | grep -i vendor' on the library file.
after some analysis it seems I need to link directly against libGLES_mali.so instead of libOpenCL.so, not sure if this is a vendor specific thing....
Ah, that might be due to libGLES_mali.so being linked to mali.so, which contains all the symbols for all the API supported by the chip's maker DDK.
Anyway, glad you solved this issue.