Android Status

Joakim via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Jan 10 19:49:42 PST 2017


On Tuesday, 10 January 2017 at 18:48:17 UTC, Ignacious wrote:
> Well, I posed a reply but I guess it didn't get though ;/
>
> I'm only suing android-x86 because I thought it would be easier 
> to test/debug. My device is a cortex-arm7.

It's probably not easier, and in any case, android-x86 won't be 
supported, largely because I don't have any working x86 devices.

> Two questions I have:
>
> 1. In the command lines present there is a lot of use of `x86`.

There shouldn't be when compiling for ARM.  The instructions for 
ARM only have it because of the path where the cross-compiler 
toolchain is stored, in a directory called 
toolchains/llvm/prebuilt/linux-x86_64/ because that's the OS and 
CPU architecture where you can run the cross-compiler.

> I used them to compile the hello world for my device and it 
> worked so I'm a bit confused. I realize there is the x86 
> binaries for compiling and then the binaries that are compiled 
> to but not sure what is what.

You are cross-compiling from linux (even though it's really a 
linux shell running in Windows) with the x86 or x86_64 CPU 
architecture to Android with the ARM CPU architecture.  As such 
the cross-compiler itself is an x86_64 binary, but produces an 
ARM object file and binary.  You have to be careful to set up the 
toolchain right or you will produce files for the wrong 
architecture.

> 2. I downloaded the native_app_glue.d and tried to compile it. 
> It imports jni.d which I found in hello-jni and I copied that 
> to the android folder and was able to compile it using 
> effectively the same command line I used to compile the working 
> hello world code.

I'm not sure why you are downloading and moving around these 
individual files.  They should all be in my android repository, 
which both pages of instructions tell you to clone.

> but when I try to then use it to compile the hello-jni sample I 
> get that it is an invalid format and many ELF relocation errors.
>
> Could you send me your working native_app_glue.o(if for the 
> cortex-arm7 or try to compile it for both cortex-arm7 and 
> x86/x64) or explain to me what is the issue with linking it in 
> and how to fix it?

No.  I'm not going to support Android/x86 and all the 
instructions are there for Android/ARM.

> cmdline that compiles android_native_app_glue.d
> bin/ldc2 -m32 -shared  -Iandroid -c android_native_app_glue.d
>
> (tried with -m64 and without either)

This won't work because my latest build of the ldc cross-compiler 
will try to compile for ARM by default.

> cmdline trying to compile hello-jni.
>
>  $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang 
> -Wl,-soname,libhello-jni.so -shared 
> --sysroot=$NDK/platforms/android-9/arch-x86 
> ../obj/local/x86/objs-debug/hello-jni/hello-jni.o 
> ../android_native_app_glue.o -lgcc  -gcc-toolchain  
> $NDK/toolchains/x86-4.8/prebuilt/linux-x86 -target 
> i686-none-linux-android -no-canonical-prefixes  
> -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now  
> -L$NDK/platforms/android-9/arch-x86/usr/lib -llog -landroid 
> -lEGL -lGLESv1_CM -llog -lc -lm -fuse-ld=bfd 
> -L../../../phobos/generated/linux/release/32 -l:libphobos2.a -o 
> ../libs/libhello-jni.so
>
> which gives the errors
>
> ....
> /usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in 
> generic ELF (EM: 40)
> /usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in 
> generic ELF (EM: 40)
> /usr/bin/ld.bfd: ../android_native_app_glue.o: Relocations in 
> generic ELF (EM: 40)
> ../android_native_app_glue.o: error adding symbols: File in 
> wrong format
> clang: error: linker command failed with exit code 1 (use -v to 
> see invocation)

It's telling you that android_native_app_glue.o is the wrong 
format, likely ARM as I noted above.  You can check the format 
with this command:

file android_native_app_glue.o

Since you're trying to create a binary for Android/x86, it cannot 
use the ARM object file to build it.

> It might be better to wait for you to finish your build setup 
> which might resolve all these problems and be more robust(I'd 
> like to be able to easily build for different platforms(for 
> testing on VM and device).

There is nothing to wait for, as I will not support Android/x86, 
certainly not anytime soon.

> But if all I need to do is get the android_native_app_glue to 
> work to run full fledged apps, then It seems I'm close? (just 
> need to compile it to the correct format?)

It may not take much more to get it working, as I did first try 
ldc with Android/x86 and left that support in.  However, it 
hasn't been tested in more than a year and so probably will 
require some fixing up.  If you want to look into that, you're on 
your own.


More information about the Digitalmars-d-learn mailing list