Broken x86-32bits when update-permissions marshmallow stuff switch api 23

[mrcmunir]

Some users report won't load x86 library http://forums.ppsspp.org/showthread.php?tid=18263&pid=116717#pid116717

This bug I reproduced on marsmallow-x86 generic image too.

Latest work is v1.1.1-370-g99fe098 https://github.com/hrydgard/ppsspp/commit/99fe0981ee3cc0b42dce6117f9eb4f484cae033e

After won't load .only view x86 missing native part popup.

[unknownbrackets]

https://github.com/hrydgard/ppsspp/commit/2d22088f3879198b6f9960068f0a8956130b2d85

What if you take the working version, and just apply the android:targetSdkVersion="23" and target=android-23 changes? I'm guessing that will cause it, if it's failing to load the x86 binary...not sure what it means.

Is anything showing up in adb logcat? Sometimes it gives more detail on the link error.

-[Unknown]

[mrcmunir]

the crash is problem when linked load libppsspp_jni.so: has text relocations

Log_2016-03-28_15-35-02.txt

Edit :: Well For some reasone compile ffmpeg with the --disable-asm flag will solve this problem but it's terryble idea disable all ffmpeg asm code for x86 slow perfomance compared than asm enabled.

I found this bug https://trac.ffmpeg.org/ticket/4928

[mrcmunir]

Google removed support text relocations for apps targeting M+ or apps targeting sdk version > 22

https://android.googlesource.com/platform/bionic/+/aa836f731016f7f1099d6a6ce47a35f1ec17dd4e https://android.googlesource.com/platform/bionic/+/e4ad91f86a47b39612e030a162f4793cb3421d31

It's Google problem i think

Edit : we need revert to Android-22 target for temporal solution for x86-32 devices?

[hrydgard]

Hm, I guess we have a wrong compile flag somewhere...

[mrcmunir]

@hrydgard https://code.google.com/p/android/issues/detail?id=191235

Text relocations are used on purpose for 32-bit x86 but google disabled support for security reason and broken several libraries has text recolations when use android-23 target .

[hrydgard]

The problem is probably that our ffmpeg is built with GCC 4.6 and without the -fpic flag which is apparently now required. I will make an attempt at rebuilding it with that flag.. I don't have any x86 Marshmallow devices though.

[mrcmunir]

with -fPIC or -fpic flag x86-32bit won't compile

/opt/android-ndk/toolchains/x86-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/i686-linux-android/4.9/../../../../i686-linux-android/bin/ld: warning: shared library text segment is not shareable libavcodec/ffv1enc.c:145: error: undefined reference to 'log2' libavcodec/ffv1enc.c:632: error: undefined reference to 'log2' libavcodec/ffv1enc.c:632: error: undefined reference to 'log2' libavcodec/ffv1enc.c:632: error: undefined reference to 'log2' libavcodec/aacsbr.c:442: error: undefined reference to 'log2f' libavcodec/aacsbr.c:470: error: undefined reference to 'log2f' libavcodec/aacsbr.c:601: error: undefined reference to 'log2f' libavutil/cpu.c:261: error: undefined reference to 'sched_getaffinity' libavutil/cpu.c:262: error: undefined reference to '__sched_cpucount' libavutil/mem.c:95: error: undefined reference to 'posix_memalign' collect2: error: ld returned 1 exit status /opt/android-ndk/build/core/build-binary.mk:665: recipe for target 'obj/local/x86/libppsspp_jni.so' failed

[unknownbrackets]

https://bugs.chromium.org/p/chromium/issues/detail?id=395287

Maybe it needs a make clean or something? Or do we need --disable-asm per the linked ffmpeg ticket? Kinda sucks.

-[Unknown]

[mrcmunir]

NDK 11 -> Have this bug... NDK 10e -> I can't reproduce compile link error.. but no has android-23 platform we need compile ffmpeg for marsmallow-x86 preven load error with x86-32bits devices.

Edit : Ok I Reproduced when compiles news ffmpeg files with GCC 4.8/4.9

[unknownbrackets]

By the way, I've tried recompiling ffmpeg on 4.9 and it still gets this error (without disable-asm.) I couldn't figure out the correct configure options to make clang build successfully, but didn't spend that much time trying.

-[Unknown]

[unknownbrackets]

Actually, it does build if I add -Wl,--no-fatal-warnings, but I assume it won't load. It doesn't have the other errors anymore (log2f, etc.)

Everything is fine and warning free with --disable-asm. But, well, don't have a device to test and likely there's a performance hit to audio/video decode.

-[Unknown]

[mrcmunir]

the log2f bug only occurs for me when compiled With FFMPEG update x86 library with newest android platform.

If you need test x86 lib you can download http://www.fosshub.com/Android-x86.html some image iso here with recents importants changes by android-x86 project with Kitkat , Lolipop and Marshmallow x86 images

Anyway I will try in the next few days

[unknownbrackets]

Ah, I see.

I got it to build with clang. It also builds fine, but also requires disable-asm. NDK changes will probably be motivating us to switch to clang anyway.

Probably I made some mistake, because I had to edit configure directly.

diff --git a/ax86-build.sh b/ax86-build.sh
index a1d8dff..1c5ac15 100755
--- a/ax86-build.sh
+++ b/ax86-build.sh
@@ -1,14 +1,21 @@
 #!/bin/bash
 #Change NDK to your Android NDK location
 NDK=/c/AndroidNDK
 PLATFORM=$NDK/platforms/android-14/arch-x86/
-PREBUILT=$NDK/toolchains/x86-4.6/prebuilt/windows-x86_64
+PREBUILT=$NDK/toolchains/x86-4.9/prebuilt/linux-x86_64
+PREBUILTLLVM=$NDK/toolchains/llvm/prebuilt/linux-x86_64

+set -e
+
+# The --disable asm flag is very unfortunate here and only needed for x86.
 GENERAL="\
    --enable-cross-compile \
-   --extra-libs="-lgcc" \
-   --cc=$PREBUILT/bin/i686-linux-android-gcc \
+   --enable-pic \
+   --disable-asm \
+   --extra-libs="-latomic" \
+   --cc=$PREBUILTLLVM/bin/clang \
    --cross-prefix=$PREBUILT/bin/i686-linux-android- \
+   --ld=$PREBUILT/bin/i686-linux-android-ld \
    --nm=$PREBUILT/bin/i686-linux-android-nm"

 MODULES="\
@@ -78,10 +85,10 @@ function build_x86
     --arch=x86 \
     ${GENERAL} \
     --sysroot=$PLATFORM \
-    --extra-cflags=" -O3 -DANDROID -Dipv6mr_interface=ipv6mr_ifindex -fasm -Wno-psabi -fno-short-enums -fno-strict-aliasing -fomit-frame-pointer -march=k8" \
+    --extra-cflags=" --target=i686-linux-android -O3 -DANDROID -Dipv6mr_interface=ipv6mr_ifindex -fasm -fno-short-enums -fno-strict-aliasing -fomit-frame-pointer -march=k8" \
     --disable-shared \
     --enable-static \
-    --extra-ldflags="-Wl,-rpath-link=$PLATFORM/usr/lib -L$PLATFORM/usr/lib -nostdlib -lc -lm -ldl -llog" \
+    --extra-ldflags="--rpath-link $PLATFORM/usr/lib -L$PLATFORM/usr/lib -L$PREBUILT/i686-linux-android/lib -nostdlib -lc -lm -ldl -llog" \
     --enable-zlib \
     --disable-everything \
     ${MODULES} \
@@ -90,7 +97,7 @@ function build_x86
     ${VIDEO_ENCODERS} \
     ${AUDIO_ENCODERS} \
     ${DEMUXERS} \
-               ${MUXERS} \
+    ${MUXERS} \
     ${PARSERS}

 make clean
diff --git a/configure b/configure
index 7f1b5c0..d347299 100755
--- a/configure
+++ b/configure
@@ -3719,8 +3719,8 @@ if test -n "$sysroot"; then
             add_cppflags --sysroot="$sysroot"
             add_ldflags --sysroot="$sysroot"
 # On Darwin --sysroot may be ignored, -isysroot always affects headers and linking
-            add_cppflags -isysroot "$sysroot"
-            add_ldflags -isysroot "$sysroot"
+            #add_cppflags -isysroot "$sysroot"
+            #add_ldflags -isysroot "$sysroot"
         ;;
         tms470)
             add_cppflags -I"$sysinclude"

Additionally, it's necessary to add -latomic to LOCAL_LDLIBS in android/jni/Locals.mk.

-[Unknown]

[unknownbrackets]

8651 and https://github.com/unknownbrackets/ppsspp-ffmpeg/tree/update3 are something you could try.

Note: I enabled runtime-detected NEON optimizations on armv7. On my Nexus 5, this appears to have improved performance a bit during the play of one video I knew I was getting wobbly FPS on. This implies that there may be a negative impact to disabling optimizations on x86, but it seems we don't have other options aside from reimplementing them ourselves.

Locally, I'm not getting any errors - but Travis is getting relocation issues linking x86_64. I don't know why yet.

-[Unknown]

[unknownbrackets]

Closing with #8651 merged - if there are still problems we can reopen. There's more detail on the above in that PR.

-[Unknown]