Dingoonity.org

You're right Retroarchs mupen core won't run on the GPD XD 

And after I did some digging in logcat I found out you're also right about the version being the problem:

E/RetroArch(  7191): Failed to open core: "/data/data/com.retroarch/cores/mupen64plus_libretro_android.so"
E/RetroArch(  7191): dlopen failed: cannot locate symbol "srand" referenced by "mupen64plus_libretro_android.so"...
In android API 19 (android 4.4.X) the function "srand()" is a static inline function invoking the function "srand48()".
In android API 20 (android 5.X) srand is defined as "void srand(unsigned int)"

So either mupen64plus needs the new srand (I doubt that as AE and FZ edition work on 4.4.4) or the guy that compiled the core did mess up and should have used "std::srand()" instead of "srand()" and compile against API version 19 or lower.

As the core is opensource you could compile your own version or open up an issue thread on libretro's github page.
I might try both if I find the time to do so.

UPDATE: looks like the libretro guys are aware that some symbols arent exporting on something older than 5.0
             still opening an issue thread might be useful if a version using std::srand works on both pre- and
             post-api20 systems

I don't know where to start to compile my own core which could possibly work.

I've tried to search to convert the Retroarch srm save file the sra format which is used by Mupen64Plus FZ standalone app but I can only find converters the other way around so I guess I'm stuck with the ParaLLei core until this is fixed or someone can point me in the right direction.

I did found the function in the file mupen64plus-core\src\main\zip\crypt.h (line 112) but I've no clue how I can compile it to a .so file which can be used in Retroarch.

Try in retroarch forums, maybe they can fix easily so you don't neeed to compile.

AFAIK the only fix for this issue is recompiling the mupen core with either utilizing the std namespace or compiling the retroarch app against api 19.

Sure, maybe someone on the RetroArch forum will recompile it or already has a working version to share still I
will try compiling the core with NDK and std::srand ASAP and will post an update if I have any success.

Ok here's a little update on how far I got.

So there is a "libretro-super"-repo for compiling retroarch for different platforms.

After downloading and installing the android SDK and NDK needed for compiling c++ code and downloading the (around 3gb large)'libretro-super'-repo for android (a horribly slow process) I used grep to find the files using srand() which are 'OpenGL.cpp' and 'crypt.h' and changed it to std::srand()
(without knowing if it would work). To compile retroarch for android you first run 'libretro-build-android-mk.sh' to build the cores so I did that and to my surprise it build most cores but not mupen  - in fact it didn't even attempt to  .

So after opening the file in a text editor I found out that it actually specifies which cores to build and some cores (for instance mupen or PPSSPP) are not on that list- so I added it just to find out that it is missing some files like a libretro.so and a jni folder with some .mk files needed by the NDK making it skip mupen when building because it doesn't know what to do with it. 

So after that I tried 'libretro-build-android-armeabi_v7a.sh' which tries to build retroarch itself requiring all the cores including, yes indeed: mupen 

Theres a tutorial for building retroarch for android but it seems to ignore the cores missing. So all-in-all the situation looks pretty bad. Lets hope for some replies on that retroarch forum thread.

I'll try again tomorrow by following the tutorial and compiling against android API 14. it's a bit desperate but maybe thats enough to make it work.

Kept you waiting huh?

So I've put a couple of days of work into this and I've made some discoveries about retroarch and android itself...

Ok my first assumption about srand being the culprit was right... kinda. srand() is a problem indeed, so is rand(), atof(), stdcpy(), stdin(), stdout(), stderr() and some more. This whole core uses references to functions that aren't implemented in android 4.4's c++ libraries    . And this whole misery is not entirely retroarch's fault; Android 4.4 is missing some pretty elementary libraries (like basic input/output-streams) which are found on most Platforms/Operating-Systems since C++11. Some of those functions where already deprecated when added to android 5.0  .

So after finding out how to compile the mupen core (It compiles against an Android NDK standalone Toolchain duuuh  ) I got myself into a huge mess with dozens of refences that only work with 5.0 and up , this might be fixable but don't get your hopes up as I am stuck at the moment (can't find the stpcpy() reference in the code) and might not be able to compile a functioning version.

Your best bet right now is searching for an older Mupen Core version (looks like Mupen was still working on 4.4 in 2016)
and hope that it works with recent retroarch versions  I haven't  had any luck myself though as libretro/retroarch doesn't keep deprecated cores.

It's crazy to think most of the cores are running even on windows 98 but android 4.4 is having problems.

THIS: https://buildbot.libretro.com/stable/archive/stable/android/armebi-v7a/1.0.0.2/cores/mupen64plus_libretro_android.so.zip

Looks like there are still some old versions of retroarch in the buildbot repo. I tested this one with retroarch 1.6.7 (newest as of now) and it seems to be working like a charm (for now at least).

should have tried looking for this sooner


I wish I had the source code for this version though, because without the source and without mirrors, this core version might get lost forever sometime in the future.