LoadLibrary on X86 Android devices running ARM code

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• patch to load from static context (patch_bug_3434.diff, text/plain, 2017-08-12 08:21:53 +0000, 3870 bytes)

Reported in version: 2.0.4
Reported for operating system, platform: Android (All), x86

Comments on the original bug report:

On 2016-09-25 10:51:48 +0000, Nix wrote:

With the move to 2.0.4 the java-wrapper for android project changes the location of the code that loads the shared-objects. Originally in the static {} constructor of SDLActivity it was moved to onCreate - On x86 devices that run emulated ARM this will crash. Moving the loadLibrary back to the static constructor fixed this.

[I can't compile x86 due to library restrictions)

On 2016-09-25 10:53:20 +0000, Nix wrote:

The bug will come in the form of unsupported e_machine: 40 bug while loading the shared-object.

On 2017-08-11 20:54:45 +0000, Sam Lantinga wrote:

Sylvain, this is a blocking bug, can you take a look at it?

Thanks!

On 2017-08-12 08:21:53 +0000, Sylvain wrote:

Created attachment 2827
patch to load from static context

Can you add more precisions to try this ?

• I have no x86 android device. Can I use an android x86 emulator on my pc, that would run emulated ARM ? How to set this up ?
• Did you try various arm abis (arm vs arm-v7a), and lastest ndk (ndk-r13b, r15).
• Maybe, in the mean-times, you would have tested a newer version of your emulator ? (is this libhoudini ?)

Indeed java code that loads the shared objects has changed, with ticket # 2759, to add a popup when shared libraries fail to load.
And also, it also allow users to customize the list of libraries to load from a subclass (https://hg.libsdl.org/SDL/rev/9a0ebeef4988).

We can revert the loading to make them from a static context, and still have a pop-up when they fail to load.
But we will lose the customisation of libraries. (Do we really need this ? shared libraries dependencies seems automatically pulled)

According to https://developer.android.com/training/articles/perf-jni.html
"The preferred way to get at your native code is to Call System.loadLibrary from a static class initializer. "

Here's a patch for that.

On 2017-08-12 22:11:17 +0000, Sam Lantinga wrote:

Nix, can you confirm that Sylvain's patch fixes the bug for you?

On 2017-08-15 08:52:46 +0000, Nix wrote:

Hi,

At the time I tested on NDK 10e. Did not test on emulator.

From what I can tell, the patch only moves the list of libraries to load to a member method rather than in-function variables. I don't see a reason this will fix the binary loading on x86 as its practically the same?

On 2017-08-23 13:37:02 +0000, Sylvain wrote:

Nix,

With the patch the libs are loaded from a static {} constructor.
As before : https://hg.libsdl.org/SDL/rev/8ebee8e28593 , as you remarked.

Can you also give more information about your testing device ?

On 2017-09-04 09:29:37 +0000, Nix wrote:

Hi,

Sorry didn't see the patch before.

I have no way of testing this now, how ever, moving it to the static constructor worked for me at the time.

My testing device was an x86 intel android device. I am not sure if all x86 will crash when not loading from static constructor.

The patch is the right solution

On 2017-09-05 11:04:40 +0000, Sylvain wrote:

Hi, and do you think you could have access to this mysterious android device again ?

On 2017-09-06 08:02:24 +0000, Nix wrote:

Sorry :/ don't have access to it anymore..

I did find the model though;
http://www.gsmarena.com/samsung_galaxy_tab_3_10_1_p5210-5478.php

Chipset Intel Atom Z2560
CPU Dual-core 1.6 GHz

On 2017-09-06 08:06:07 +0000, Sam Lantinga wrote:

This might help?
https://software.intel.com/en-us/android/articles/intel-atom-x86-image-for-android-4-4-kitkat-installation-instructions-manually

On 2017-09-06 08:08:17 +0000, Nix wrote:

I have never tried running the emulator so I don't really know.. I figured its not that good with graphics/heavy real time

On 2017-09-06 11:16:42 +0000, Sylvain wrote:

I tried the x86 emulator, but I think it has no arm translation brige enabled.
When I run an ARM .apk, it does not find the shared libraries.
So it does not even try to translate and execute them.

On 2017-09-06 11:41:06 +0000, Sylvain wrote:

from this link https://software.intel.com/en-us/android/articles/intel-architecture-support-guide-for-android-middleware-providers

When having support for 3rd party plugins that can embed architecture-specific binaries, like Unity has, attention should be given to be sure these plugins are compatible with all the supported platforms. Before Android 5.0, it was possible to still load ARM libs from an x86 folder. But this isn’t possible anymore and leads to errors such has “dlopen failed: ‘libMyLib.so’ has unexpected e_machine: 40”. So plugins have to be upgraded to also include x86 binaries and the engine/service has to enforce that, in order to allow a smooth transition.

maybe you were also loading your arm library from the x86 folder ?

On 2017-09-06 12:17:30 +0000, Nix wrote:

Nope, our project only has ARM binaries, located in app\src\main\jniLibs\armeabi-v7a

On 2018-12-30 13:28:36 +0000, Sylvain wrote:

Closing it

• SDL2 is choosing to load libraries dynamically.

• SDL2 now support "relinker":
  https://github.com/KeepSafe/ReLinker
  https://hg.libsdl.org/SDL/rev/f4dde3c6bae9