We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

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

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

Thanks!

Created attachment 2827 [details]
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.

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

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?

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 ?

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

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

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

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

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

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.

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 ?

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

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