Linking shared library libGLES_mali.so causes dlopen failed: library "android.hardware.graphics.common@1.0.so" not found
1,330 views
Skip to first unread message
Rodolfo Rocco
Jan 25, 2019, 11:30:37 AM1/25/19
to android-ndk
Hi everyone,
I've been working for years on this application that uses libGLES_mali.so for OpenCL integration. Everything about cmake.txt should be fine as I've been working on the app for a long time as I said. Since I started testing the app on a new device with android 8.1 I've been getting the error in the title when I try loading libGLES_mali.so. My understanding is that this is due to the changes introduced with android nougat in the way native libraries are loaded. However the thing is that I've bundled libGLES_mali.so in my apk. I've tried bundling the mentioned library (android.hardware...@1.0.so) in my apk too with no success. Any suggestion?
Shahriar Vaghar
Jan 25, 2019, 1:16:27 PM1/25/19
to andro...@googlegroups.com
1- Send the entire run-time error.
2- cp libGLES_mali.so to /system/lib[64]. Does it still fail?
On Fri, Jan 25, 2019 at 8:30 AM Rodolfo Rocco <fairfr...@gmail.com> wrote:
Hi everyone,I've been working for years on this application that uses libGLES_mali.so for OpenCL integration. Everything about cmake.txt should be fine as I've been working on the app for a long time as I said. Since I started testing the app on a new device with android 8.1 I've been getting the error in the title when I try loading libGLES_mali.so. My understanding is that this is due to the changes introduced with android nougat in the way native libraries are loaded. However the thing is that I've bundled libGLES_mali.so in my apk. I've tried bundling the mentioned library (android.hardware...@1.0.so) in my apk too with no success. Any suggestion?
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/0f517b35-480c-4dce-8a1a-736f04399a05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Dan Albert
Jan 25, 2019, 1:30:03 PM1/25/19
to android-ndk
Why are you directly linking to the vendor specific implementation rather than to the public library, libGLES?
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAPwkQFEQ3znavnAaggnQradnX3eCrFo_3-ZXZKp1sGsayp-SJw%40mail.gmail.com.
Rodolfo Rocco
Jan 25, 2019, 3:40:44 PM1/25/19
to android-ndk
1-
java.lang.UnsatisfiedLinkError: dlopen failed: library "android.hardware...@1.0.so" not found
Happens when I Sytem.Load the library
2- You mean that I should copy the library from the egl subfolder to its parent directory?
Il giorno venerdì 25 gennaio 2019 19:16:27 UTC+1, Shahriar Vaghar ha scritto:
1- Send the entire run-time error.2- cp libGLES_mali.so to /system/lib[64]. Does it still fail?
On Fri, Jan 25, 2019 at 8:30 AM Rodolfo Rocco <fairfr...@gmail.com> wrote:
Hi everyone,I've been working for years on this application that uses libGLES_mali.so for OpenCL integration. Everything about cmake.txt should be fine as I've been working on the app for a long time as I said. Since I started testing the app on a new device with android 8.1 I've been getting the error in the title when I try loading libGLES_mali.so. My understanding is that this is due to the changes introduced with android nougat in the way native libraries are loaded. However the thing is that I've bundled libGLES_mali.so in my apk. I've tried bundling the mentioned library (android.hardware.graphics.com...@1.0.so) in my apk too with no success. Any suggestion?
Rodolfo Rocco
Jan 25, 2019, 3:40:44 PM1/25/19
to android-ndk
Because, to my knowledge, only the vendor specific one contains the OpenCL symbols. Other vendors put them in libOpencl.so but ARM put them in libGLES_mali together with the OpenGL ones.
Il giorno venerdì 25 gennaio 2019 19:30:03 UTC+1, Dan Albert ha scritto:
Why are you directly linking to the vendor specific implementation rather than to the public library, libGLES?
On Fri, Jan 25, 2019, 10:16 Shahriar Vaghar <sva...@gmail.com wrote:
1- Send the entire run-time error.2- cp libGLES_mali.so to /system/lib[64]. Does it still fail?
On Fri, Jan 25, 2019 at 8:30 AM Rodolfo Rocco <fairfr...@gmail.com> wrote:
Hi everyone,I've been working for years on this application that uses libGLES_mali.so for OpenCL integration. Everything about cmake.txt should be fine as I've been working on the app for a long time as I said. Since I started testing the app on a new device with android 8.1 I've been getting the error in the title when I try loading libGLES_mali.so. My understanding is that this is due to the changes introduced with android nougat in the way native libraries are loaded. However the thing is that I've bundled libGLES_mali.so in my apk. I've tried bundling the mentioned library (android.hardware.graphics.com...@1.0.so) in my apk too with no success. Any suggestion?
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/0f517b35-480c-4dce-8a1a-736f04399a05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Shahriar Vaghar
Jan 25, 2019, 4:19:02 PM1/25/19
to andro...@googlegroups.com
Not necessary to copy.
linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-readelf -d libGLES_android.so | grep NEEDED
0x00000001 (NEEDED) Shared library: [libcutils.so]
0x00000001 (NEEDED) Shared library: [libhardware.so]
0x00000001 (NEEDED) Shared library: [libutils.so]
0x00000001 (NEEDED) Shared library: [liblog.so]
0x00000001 (NEEDED) Shared library: [libpixelflinger.so]
0x00000001 (NEEDED) Shared library: [libETC1.so]
0x00000001 (NEEDED) Shared library: [libui.so]
0x00000001 (NEEDED) Shared library: [libnativewindow.so]
0x00000001 (NEEDED) Shared library: [libc++.so]
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000001 (NEEDED) Shared library: [libm.so]
0x00000001 (NEEDED) Shared library: [libdl.so]
On Fri, Jan 25, 2019 at 12:40 PM Rodolfo Rocco <fairfr...@gmail.com> wrote:
1-
java.lang.UnsatisfiedLinkError: dlopen failed: library "android.hardware...@1.0.so" not foundHappens when I Sytem.Load the library2- You mean that I should copy the library from the egl subfolder to its parent directory?
Il giorno venerdì 25 gennaio 2019 19:16:27 UTC+1, Shahriar Vaghar ha scritto:
1- Send the entire run-time error.2- cp libGLES_mali.so to /system/lib[64]. Does it still fail?
On Fri, Jan 25, 2019 at 8:30 AM Rodolfo Rocco <fairfr...@gmail.com> wrote:
Hi everyone,I've been working for years on this application that uses libGLES_mali.so for OpenCL integration. Everything about cmake.txt should be fine as I've been working on the app for a long time as I said. Since I started testing the app on a new device with android 8.1 I've been getting the error in the title when I try loading libGLES_mali.so. My understanding is that this is due to the changes introduced with android nougat in the way native libraries are loaded. However the thing is that I've bundled libGLES_mali.so in my apk. I've tried bundling the mentioned library (android.hardware...@1.0.so) in my apk too with no success. Any suggestion?
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/0f517b35-480c-4dce-8a1a-736f04399a05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/a6efd6bf-9389-49b5-bfde-0e2321651289%40googlegroups.com.
Rodolfo Rocco
Jan 28, 2019, 4:09:50 AM1/28/19
to android-ndk
Yeh, but I need to use libGLES_mali.so and this is the output of readelf
Rodolfos-MacBook-Air:bin rodolforocco$ ./readelf -d /Users/rodolforocco/AndroidProjects/OvermindClient/app/libs/arm64-v8a/android-27/libGLES_mali.so | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [android.hardware...@1.0.so]
0x0000000000000001 (NEEDED) Shared library: [liblog.so]
0x0000000000000001 (NEEDED) Shared library: [libnativewindow.so]
0x0000000000000001 (NEEDED) Shared library: [libz.so]
0x0000000000000001 (NEEDED) Shared library: [libc++.so]
0x0000000000000001 (NEEDED) Shared library: [libutils.so]
0x0000000000000001 (NEEDED) Shared library: [libcutils.so]
0x0000000000000001 (NEEDED) Shared library: [libm.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
And as you can see android.hardware...@1.0.so IS included. But even if bundle it in the app it cannot be found by System.loadLibrary
Il giorno venerdì 25 gennaio 2019 22:19:02 UTC+1, Shahriar Vaghar ha scritto:
Not necessary to copy.
linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-readelf -d libGLES_android.so | grep NEEDED0x00000001 (NEEDED) Shared library: [libcutils.so]0x00000001 (NEEDED) Shared library: [libhardware.so]0x00000001 (NEEDED) Shared library: [libutils.so]0x00000001 (NEEDED) Shared library: [liblog.so]0x00000001 (NEEDED) Shared library: [libpixelflinger.so]0x00000001 (NEEDED) Shared library: [libETC1.so]0x00000001 (NEEDED) Shared library: [libui.so]0x00000001 (NEEDED) Shared library: [libnativewindow.so]0x00000001 (NEEDED) Shared library: [libc++.so]0x00000001 (NEEDED) Shared library: [libc.so]0x00000001 (NEEDED) Shared library: [libm.so]0x00000001 (NEEDED) Shared library: [libdl.so]
On Fri, Jan 25, 2019 at 12:40 PM Rodolfo Rocco <fairfr...@gmail.com> wrote:
1-java.lang.UnsatisfiedLinkError: dlopen failed: library "android.hardware.graphics.com...@1.0.so" not found
Happens when I Sytem.Load the library2- You mean that I should copy the library from the egl subfolder to its parent directory?
Il giorno venerdì 25 gennaio 2019 19:16:27 UTC+1, Shahriar Vaghar ha scritto:
1- Send the entire run-time error.2- cp libGLES_mali.so to /system/lib[64]. Does it still fail?
On Fri, Jan 25, 2019 at 8:30 AM Rodolfo Rocco <fairfr...@gmail.com> wrote:
Hi everyone,I've been working for years on this application that uses libGLES_mali.so for OpenCL integration. Everything about cmake.txt should be fine as I've been working on the app for a long time as I said. Since I started testing the app on a new device with android 8.1 I've been getting the error in the title when I try loading libGLES_mali.so. My understanding is that this is due to the changes introduced with android nougat in the way native libraries are loaded. However the thing is that I've bundled libGLES_mali.so in my apk. I've tried bundling the mentioned library (android.hardware.graphics.com...@1.0.so) in my apk too with no success. Any suggestion?
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/0f517b35-480c-4dce-8a1a-736f04399a05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rodolfo Rocco
Jan 29, 2019, 3:55:48 AM1/29/19
to android-ndk
Has someone any suggestion? I find it hard to believe that it is simply impossible now to create OpenCL applications.
Il giorno lunedì 28 gennaio 2019 10:09:50 UTC+1, Rodolfo Rocco ha scritto:
Yeh, but I need to use libGLES_mali.so and this is the output of readelf
Rodolfos-MacBook-Air:bin rodolforocco$ ./readelf -d /Users/rodolforocco/AndroidProjects/OvermindClient/app/libs/arm64-v8a/android-27/libGLES_mali.so | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [android.hardware.graphics.com...@1.0.so]
0x0000000000000001 (NEEDED) Shared library: [liblog.so]
0x0000000000000001 (NEEDED) Shared library: [libnativewindow.so]
0x0000000000000001 (NEEDED) Shared library: [libz.so]
0x0000000000000001 (NEEDED) Shared library: [libc++.so]
0x0000000000000001 (NEEDED) Shared library: [libutils.so]
0x0000000000000001 (NEEDED) Shared library: [libcutils.so]
0x0000000000000001 (NEEDED) Shared library: [libm.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
And as you can see android.hardware.graphics.com...@1.0.so IS included. But even if bundle it in the app it cannot be found by System.loadLibrary
Chris Browet
Jan 30, 2019, 6:22:37 PM1/30/19
to android-ndk
Assuming the "libGLES_mali.so"comes with the new device, definitely looks like a device specific issue.
I might be wrong, but I think "android.hardware...@1.0.so" is a vendor specific library.
Rodolfo Rocco
Jan 31, 2019, 10:36:34 AM1/31/19
to android-ndk
libGLES_mali.so does come from the device I'm testing the application on. android.hardware.graphics.com...@1.0.so is actually part of vndk-sp, as can be seen here. I thought that third-party libraries were allowed to depend on libraries which are part of vndk-sp. In any case I found android.hardware.graphics.com...@1.0.so in the /system/lib64/ folder of my device, so I don't think it's vendor specific (otherwise I suppose I would have found it in /system/vendor/lib64 or in /vendor/lib64/)
Il giorno giovedì 31 gennaio 2019 00:22:37 UTC+1, Chris Browet ha scritto:
Assuming the "libGLES_mali.so"comes with the new device, definitely looks like a device specific issue.
I might be wrong, but I think "android.hardware.graphics.com...@1.0.so" is a vendor specific library.
Philippe Simons
Jan 31, 2019, 5:52:50 PM1/31/19
to android-ndk
I might be wrong, but I think "android.hardware...@1.0.so" is a vendor specific library.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/826bdf62-ac61-4719-85a9-0ccd24e233c7%40googlegroups.com.
Philippe Simons
Jan 31, 2019, 5:56:03 PM1/31/19
to android-ndk
Rodolfo Rocco
Feb 1, 2019, 3:52:34 PM2/1/19
to android-ndk
I solved the problem by loading the library separately as soon as possible. In order to do so I had to also include all the libraries that android...common@1.0.so itself depends on. More details can be found in the stackoverflow answer I give at this link.
Il giorno giovedì 31 gennaio 2019 23:56:03 UTC+1, Philippe Simons ha scritto:
On Thu, Jan 31, 2019 at 11:52 PM Philippe Simons <simons....@gmail.com> wrote:
On Thu, Jan 31, 2019 at 4:36 PM Rodolfo Rocco <fairfr...@gmail.com> wrote:
libGLES_mali.so does come from the device I'm testing the application on. android.hardware.graphics.com...@1.0.so is actually part of vndk-sp, as can be seen here. I thought that third-party libraries were allowed to depend on libraries which are part of vndk-sp. In any case I found android.hardware.graphics.commo...@1.0.so in the /system/lib64/ folder of my device, so I don't think it's vendor specific (otherwise I suppose I would have found it in /system/vendor/lib64 or in /vendor/lib64/)
Il giorno giovedì 31 gennaio 2019 00:22:37 UTC+1, Chris Browet ha scritto:
Assuming the "libGLES_mali.so"comes with the new device, definitely looks like a device specific issue.
I might be wrong, but I think "android.hardware.graphics.com...@1.0.so" is a vendor specific library.
Reply all
Reply to author
Forward
0 new messages