Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android 32 bit binary does not work #433

Closed
Elvecent opened this issue Jan 1, 2019 · 9 comments · Fixed by #480
Closed

Android 32 bit binary does not work #433

Elvecent opened this issue Jan 1, 2019 · 9 comments · Fixed by #480
Labels

Comments

@Elvecent
Copy link

Elvecent commented Jan 1, 2019

Hi

I've run into a problem with reflex-platform while trying to test the apk file I built on my physical device (which is Motorola Moto E4).

Upon launch, the app shows white screen for less than a second and closes immediately with no content rendered and no errors shown. I've tested the app on a different physical device and it worked as expected.

The code was just a simple text widget (hello world variety), built precisely as prescribed in project-development.md. I'm entirely new to android platform, so I have no idea what went wrong and how to debug it.

I hope something can be done about this? Thanks in advance!

@luigy
Copy link
Member

luigy commented Jan 3, 2019

I wonder if this device is 32-bit which is not supported/working atm. When #312 landed we didn't get enough time to get this sorted out, but there is a chance there is not much left to do. If not 32-bit then you may get some more info from adb logcat

@Elvecent
Copy link
Author

Elvecent commented Jan 3, 2019

The device has a 64 bit ARMv8 CPU but for some reason the instruction set utilized is 32 bit (Motorola does this when the device has less than 4gb RAM). Alright, good to know that this is a known problem.

@matthewbauer
Copy link
Member

The reflex platform binaries should have 32 bit and 64 bit versions. It's possible the 32 bit ones are broken though.

@dfordivam dfordivam changed the title Android 7.1.1 application failure Android 32 bit binary does not work Jan 25, 2019
@dfordivam dfordivam added the bug label Jan 25, 2019
@rvl
Copy link

rvl commented Mar 24, 2019

I think I have the same issue on a Google Nexus 5 (also has a 32-bit CPU). I take the latest revision of reflex-platform (a7f6394) and use it with reflex-project-skeleton.

The resulting app (nix-build -A android.frontend), when deployed, crashes on startup. adb logcat reports the following:

03-24 12:43:15.099  2439  2821 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=org.example.frontend/systems.obsidian.HaskellActivity (has extras)} from uid 10030 on display 0
03-24 12:43:15.117  2439  2453 W BroadcastQueue: Permission Denial: receiving Intent { act=com.android.launcher3.action.LAUNCH flg=0x10 (has extras) } to com.google.android.gms/.chimera.GmsIntentOperationService$GmsExternalReceiver requires com.android.launcher3.permission.RECEIVE_LAUNCH_BROADCASTS due to sender com.cyanogenmod.trebuchet (uid 10030)
03-24 12:43:15.139 10673 10673 I art     : Late-enabling -Xcheck:jni
03-24 12:43:15.164  2439 19568 I ActivityManager: Start proc 10673:org.example.frontend/u0a144 for activity org.example.frontend/systems.obsidian.HaskellActivity
03-24 12:43:15.261 10673 10689 D HaskellActivity: Logger running
03-24 12:43:15.262 10673 10689 D HaskellActivity: jsaddle: unknown RTS option: -N2
03-24 12:43:15.263 10673 10689 D HaskellActivity: jsaddle: 
03-24 12:43:15.263 10673 10689 D HaskellActivity: jsaddle: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
03-24 12:43:15.267 10673 10689 D HaskellActivity: jsaddle: <snip snip>
03-24 12:43:15.274 10673 10690 D HaskellActivity: Haskell main action exited with status 1
03-24 12:43:15.346  2439  3474 D WindowManager: relayoutVisibleWindow: Window{b8a5e6f u0 com.cyanogenmod.trebuchet/com.android.launcher3.Launcher EXITING} mAnimatingExit=true, mRemoveOnExit=false, mDestroying=false

@kmicklas
Copy link
Contributor

This seems possibly relevant: https://gitlab.haskell.org/ghc/ghc/issues/12929.

However it's unclear how this used to work, especially since we were using GHC 8.0 (where this was reported) previously.

@kmicklas
Copy link
Contributor

Even more relevant looking context: https://gitlab.haskell.org/ghc/ghc/issues/12981

@kmicklas
Copy link
Contributor

> /nix/store/0yr60dfiaayimbgwlnlgia8yqzp348ca-armv7a-unknown-linux-androideabi-ghc-8.4.3/bin/armv7a-unknown-linux-androideabi-ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv -fno-builtin")
 ,("C compiler command","/nix/store/bqksmlqnid8jxv656fwip8pv7xzik6sq-armv7a-unknown-linux-androideabi-ndk-gcc-binutils-wrapper/bin/armv7a-unknown-linux-androideabi-cc")
 ,("C compiler flags"," -std=gnu99 -marm -fno-stack-protector")
 ,("C compiler link flags","-fuse-ld=gold  -Wl,-z,noexecstack")
 ,("C compiler supports -no-pie","YES")
 ,("Haskell CPP command","/nix/store/bqksmlqnid8jxv656fwip8pv7xzik6sq-armv7a-unknown-linux-androideabi-ndk-gcc-binutils-wrapper/bin/armv7a-unknown-linux-androideabi-cc")
 ,("Haskell CPP flags","-E -undef -traditional")
 ,("ld command","/nix/store/96yr280akf2jalrsrxdqzm2jrbqs360s-armv7a-unknown-linux-androideabi-ndk-gcc-binutils-wrapper/bin/armv7a-unknown-linux-androideabi-ld.gold")
 ,("ld flags"," -z noexecstack")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","YES")
 ,("ld supports filelist","NO")
 ,("ld is GNU ld","YES")
 ,("ar command","armv7a-unknown-linux-androideabi-ar")
 ,("ar flags","q")
 ,("ar supports at file","YES")
 ,("ranlib command","/nix/store/qf11f43nkdgx4ks7d16irwsl1ax2d5ns-ndk-gcc-binutils/bin/armv7a-unknown-linux-androideabi-ranlib")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/nix/store/jpdrxba87xm2kkxf7skdh8imszv5zc5n-perl-5.28.1/bin/perl")
 ,("cross compiling","YES")
 ,("target os","OSLinux")
 ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = SOFT}")
 ,("target word size","4")
 ,("target has GNU nonexec stack","True")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","False")
 ,("target has RTS linker","YES")
 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("LLVM clang command","clang")
 ,("Project version","8.4.3")
 ,("Project Git commit id","51abb1c88b53e2989a2a8c2939ac4abc04bef194")
 ,("Booter version","8.2.1")
 ,("Stage","1")
 ,("Build platform","x86_64-unknown-linux")
 ,("Host platform","x86_64-unknown-linux")
 ,("Target platform","arm-unknown-linux-android")
 ,("Have interpreter","YES")
 ,("Object splitting supported","NO")
 ,("Have native code generator","NO")
 ,("Support SMP","NO")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn")
 ,("RTS expects libdw","NO")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Support Backpack","YES")
 ,("Requires unified installed package IDs","YES")
 ,("Uses package keys","YES")
 ,("Uses unit IDs","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","NO")
 ,("GHC Profiled","NO")
 ,("Leading underscore","NO")
 ,("Debug on","False")
 ,("LibDir","/nix/store/0yr60dfiaayimbgwlnlgia8yqzp348ca-armv7a-unknown-linux-androideabi-ghc-8.4.3/lib/armv7a-unknown-linux-androideabi-ghc-8.4.3")
 ,("Global Package DB","/nix/store/0yr60dfiaayimbgwlnlgia8yqzp348ca-armv7a-unknown-linux-androideabi-ghc-8.4.3/lib/armv7a-unknown-linux-androideabi-ghc-8.4.3/package.conf.d")
 ]

The problem is armISA = ARMv5. Only armv7 (which is what we're trying to build with) supports the threaded runtime.

@rvl
Copy link

rvl commented Mar 27, 2019

Ah, I see ARM_ISA = ARMv5 ⇒ ArchSupportsSMP = NO, as you said. Thanks for looking in to it! Do you think this is a bug in nixpkgs or the GHC build system?

@kmicklas
Copy link
Contributor

@rvl It's definitely intended that v5 and v6 don't support SMP, but how it's getting v5 when our platform triple is clearly armv7 I'm not sure. I'm testing a patch now that just forces GET_ARM_ISA to report v7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants