How difficult is it to build for x86/x64?

Would be nice to be able to use something like

http://www.android-x86.org/

as a test instead of an actual device.

Does one simply have to use the proper ldc2/dmd and link in the correct libs? or is it more complex?

Also, I'm a bit confused on how to compile the source examples(working it out and trying to explain the solutions as I type)

https://wiki.dlang.org/Build_DMD_for_Android

(set $NDK permanently)
I have done(easy, find the file and modify)

    rt_init();
    android_main(android_app);
    rt_term();

Clean up and compile as before:

$NDK/ndk-build clean
NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1

But no error. Object files for various architectures are created though, it seems. (rt_ errors do no exist contrary to what is said in the docs)


But the following seems need updating/explaining. I am using prebuilt ldc2 for android from some link you provided. -android doesn't seem to work and I can't find sensor.d (not sure if it is needed anymore)?

../../../dmd/src/dmd -android -I../.. -ofobj/local/x86/objs/native-activity main.o -c jni/main.d ../../android/sensor.d

I had to change to use ldc2, remove -android, and obviously change the file names and such(and download the android dir from github).

$NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang -Wl,-soname,libnative-activity.so -shared --sysroot=$NDK/platforms/android-9/arch-x86 ./obj/local/x86/objs/native-activity/main.o ./obj/local/x86/libandroid_native_app_glue.a -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/x86/libnative-activity.so

Seems a lot of the paths are wrong/different than what I have

$NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang -Wl,-soname,libhello-jni.so -shared --sysroot=$NDK/platforms/android-9/arch-x86 ./obj/local/x86/objs-debug/hello-jni/main.o ./obj/local/x86/libandroid_native_app_glue.a -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/x86/libhello-jni.so


I am going to zip of what I have so you can see how the paths are laid out: http://www.filedropper.com/ldc2android

There seems to be no obj file generated except for debug, that was probably intentional but the given command line doesn't represent that if so.


It is a bit confusing for the beginner to come along and try to get all this to work when there is contradictory information. The reason being is simple in that a beginner won't know what is used for what and the docs essentially are give as "plug and play" yet don't actually work... rather than being descriptive and explaining exactly what is what(some of it should be obvious but not all will be to someone that isn't versed in linux and android development or used to windows which abstracts everything).

What would be nice, at a minim, is a bash script that allows one to adjust different variables for different situations and then it can be used to compile. (e.g., set the obj path, ndk path, ldc2 path, etc)

What really needs to be done, IMO, is to have a simple set of tools(scripts or whatever) that can be configured easily and abstracts the complexity. (I've done that for the test script I made

#!/bin/bash

/mnt/c/dlang/ldc2Android/bin/ldc2 -c $1.d

$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -Wl,-z,nocopyreloc --sysroot=$NDK/platforms/android-9/arch-arm -lgcc -gcc-toolchain $NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -target armv7-none-linux-androideabi -no-canonical-prefixes -fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fPIE -pie -mthumb -Wl,--export-dynamic -lc -lm $1.o lib/libphobos2-ldc.a lib/libdruntime-ldc.a -o $1


which does the compiling for me without having to type all that junk in each time.. pretty simple but does the job, a more advanced concept could be used to help make it easier on people
)

If you want, and you can accomplish this, if there was an ldc2/dmd2 for android that runs on windows I could work on getting it working for windows(as I prefer it rather than linux, which I have no real experience with). I'm thinking everything more or less would work similarly(since sdk/ndk exists for windows). It would just be a matter of translating paths and such. I could easily write a wrapper to reduce the complexity.


The main problem I seem to be having are path issues(e.g,

$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang

rather than

$NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang

,etc)


The final error I get is

clang: error: no such file or directory: './obj/local/x86/libandroid_native_app_glue.a'

and I can't find this file anywhere.

I assume I was suppose to get this file when I did

$NDK/ndk-build clean
NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1

You should see the following linker error, as the linker can't find the rt_init and rt_term functions you just added:

/home/joakim/android-ndk-r10/sources/android/native_app_glue/android_native_app_glue.c:232:
error: undefined reference to 'rt_init'
/home/joakim/android-ndk-r10/sources/android/native_app_glue/android_native_app_glue.c:234:
error: undefined reference to 'rt_term'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [obj/local/x86/libnative-activity.so] Error 1

but I didn't.

If I execute that command in the android_native_app_glue.c dir I get

/opt/android-ndk-r13b/sources/android/native_app_glue# NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
Android NDK: Could not find application project directory !
Android NDK: Please define the NDK_PROJECT_PATH variable to point to it.
/opt/android-ndk-r13b/build/core/build-local.mk:151: *** Android NDK: Aborting    .  Stop.

Of course, if I execute it in the project path I get a lot of stuff but not that file anywhere.

I have dried to put

android_native_app_glue.d

in different places but nothing...

Once that is fixed I assume everything should work... but I'm at a loss for what to do next. Any ideas?

Basically we have andorid_native_app_glue.c which we modify with rt_init and rt_term. We have a d file of that which I don't know what to do with. I see that somewhere in the compiling of the of the sample file that it is used but I'm unsure of what is what and how to go about getting android_native_app_glue.a(is it the d version compiled, something that comes from the ndk, or what?)



(sorry for the mess, was trying stuff as I went along)

On Monday, 9 January 2017 at 18:38:01 UTC, Ignacious wrote:
> On Monday, 9 January 2017 at 08:28:04 UTC, Joakim wrote:
>> I've tried to write up detailed instructions on the wiki.  I'm still improving those and plan to spin off those two sections I linked you, on how to just build the samples, into their own page.  You can contribute any steps you had to take with Bash/Ubuntu on Windows with the prebuilt linux/x64 cross-compiler there, once I put the page up.
>
>
> Yeah, I found it a bit confusing though. It seems like it is written up by someone that is working on the core rather than a newb! ;)

Yep, that's what it is.  That's one reason why I want to add another wiki page which will just focus on building the sample apps, as opposed to building the cross-compiler too.

>>> The main problem I have had seems to be that UoW uses ver 14. Somehow I was able to upgrade by following docs online(wasn't easy but eventually got there and everything seems to work... I should have documented ;) but I wasn't sure if the process would work. Supposedly ver 16 exists by one has to be part of the dev team or something.
>>
>> If you know all the steps to upgrade Ubuntu on Windows, you may want to document them on the wiki page I will put up or link to a good resource that shows how to do it.
>
>
> I don't because it was all new to me(I didn't know there was even such a thing as UoW.  I simply searched for the errors I got and tried different solutions until it worked. Luckily the outcome worked... which is not always the case.

Is it easy for you to nuke it and go back to the original 14.04 setup?  I may be able to remove some of those ldc library dependencies, so that it works on the original setup too.

> I think that it would be a boon for D to have some type of well defined and well planned Android development suite rather than what seems to be hacked/cobbled together. This would bring not only more developers to D for android but also to D in general.

Yes, definitely the plan.  The big problem right now is that it requires a slightly modified llvm.  If that weren't needed, we could just have the official release builders also build the standard library for Android/ARM on their OS.

> I'm gonna try the opengl examples and hopefully the work. The main problem I see is how to actually write "commercial" apps using D for android. Can it be done successfully? Nobody knows because there isn't a history. What are the exact steps, say, to add ads, or interface with the subsystem? I saw that there is some way to call some java stuff from D but seems like nothing is thoroughly tested(most of the work as been just trying to get things up and running).

I got interfacing with Java working late last year, through JNI.  Not "thoroughly tested" by any means, but seems to work.  The only way to know whether commercial Android apps can be written in D is to actually do it.  I plan on writing one this year.

On Monday, 9 January 2017 at 23:24:08 UTC, Ignacious wrote:
> How difficult is it to build for x86/x64?
>
> Would be nice to be able to use something like
>
> http://www.android-x86.org/
>
> as a test instead of an actual device.
>
> Does one simply have to use the proper ldc2/dmd and link in the correct libs? or is it more complex?

Not too hard.  I haven't bothered with it because Android/x86 had almost no market share, and Intel has essentially given up and pulled out of that market.  I may someday update it again, but the problem right now is that I don't have an x86 machine on which to try it.  I've gone all ARM and setting Android/x86 up on a VPS takes some work.

> Also, I'm a bit confused on how to compile the source examples(working it out and trying to explain the solutions as I type)
>
> https://wiki.dlang.org/Build_DMD_for_Android

As noted there, those instructions haven't been updated in a year and a half and are out of date.  I just updated the wiki page with a stronger warning.

> (set $NDK permanently)
> I have done(easy, find the file and modify)
>
>     rt_init();
>     android_main(android_app);
>     rt_term();
>
> Clean up and compile as before:
>
> $NDK/ndk-build clean
> NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
>
> But no error. Object files for various architectures are created though, it seems. (rt_ errors do no exist contrary to what is said in the docs)

I'm not sure why that wouldn't error anymore, it should be the same.  Anyway, since I wrote those instructions a couple years ago, I translated the google-provided android_native_app_glue.c to android_native_app_glue.d and didn't bother updating the instructions for Android/x86.

> But the following seems need updating/explaining. I am using prebuilt ldc2 for android from some link you provided. -android doesn't seem to work and I can't find sensor.d (not sure if it is needed anymore)?
>
> ../../../dmd/src/dmd -android -I../.. -ofobj/local/x86/objs/native-activity main.o -c jni/main.d ../../android/sensor.d
>
> I had to change to use ldc2, remove -android, and obviously change the file names and such(and download the android dir from github).
>
> $NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang -Wl,-soname,libnative-activity.so -shared --sysroot=$NDK/platforms/android-9/arch-x86 ./obj/local/x86/objs/native-activity/main.o ./obj/local/x86/libandroid_native_app_glue.a -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/x86/libnative-activity.so
>
> Seems a lot of the paths are wrong/different than what I have
>
> $NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang -Wl,-soname,libhello-jni.so -shared --sysroot=$NDK/platforms/android-9/arch-x86 ./obj/local/x86/objs-debug/hello-jni/main.o ./obj/local/x86/libandroid_native_app_glue.a -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/x86/libhello-jni.so
>
>
> I am going to zip of what I have so you can see how the paths are laid out: http://www.filedropper.com/ldc2android
>
> There seems to be no obj file generated except for debug, that was probably intentional but the given command line doesn't represent that if so.
>
>
> It is a bit confusing for the beginner to come along and try to get all this to work when there is contradictory information.

Yes, that wiki page notes that it is out of date, which accounts for most of the issues you noted.

> The reason being is simple in that a beginner won't know what is used for what and the docs essentially are give as "plug and play" yet don't actually work... rather than being descriptive and explaining exactly what is what(some of it should be obvious but not all will be to someone that isn't versed in linux and android development or used to windows which abstracts everything).
>
> What would be nice, at a minim, is a bash script that allows one to adjust different variables for different situations and then it can be used to compile. (e.g., set the obj path, ndk path, ldc2 path, etc)
>
> What really needs to be done, IMO, is to have a simple set of tools(scripts or whatever) that can be configured easily and abstracts the complexity. (I've done that for the test script I made
>
> #!/bin/bash
>
> /mnt/c/dlang/ldc2Android/bin/ldc2 -c $1.d
>
> $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -Wl,-z,nocopyreloc --sysroot=$NDK/platforms/android-9/arch-arm -lgcc -gcc-toolchain $NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -target armv7-none-linux-androideabi -no-canonical-prefixes -fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fPIE -pie -mthumb -Wl,--export-dynamic -lc -lm $1.o lib/libphobos2-ldc.a lib/libdruntime-ldc.a -o $1
>
>
> which does the compiling for me without having to type all that junk in each time.. pretty simple but does the job, a more advanced concept could be used to help make it easier on people
> )

As I noted elsewhere, I am writing reggae files to automate building the sample apps.  The problem right now is that I have to rewrite my reggae files to work with an external linker from the NDK, as opposed to the native linker on my Android/ARM tablet:

https://github.com/atilaneves/reggae/issues/22

Once that's done, I will commit them to my Android repo so that anyone can use them with reggae.  The new wiki page will have instructions on how to use it all together, while keeping the old manual instructions around so you can see what they're actually doing.

> If you want, and you can accomplish this, if there was an ldc2/dmd2 for android that runs on windows I could work on getting it working for windows(as I prefer it rather than linux, which I have no real experience with). I'm thinking everything more or less would work similarly(since sdk/ndk exists for windows). It would just be a matter of translating paths and such. I could easily write a wrapper to reduce the complexity.

I have not used Windows in more than a year.  We used to have two Windows devices at home 3-4 years ago, a laptop and an ultrabook, now we have none.  I suppose I could try setting up wine in a VPS, but I'm not sure if that'd work and don't feel inclined to try it.  As I said earlier, when this cross-compiler can use stock llvm, there will be official cross-compilers for every OS.

> The main problem I seem to be having are path issues(e.g,
>
> $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
>
> rather than
>
> $NDK/toolchains/llvm-3.5/prebuilt/linux-x86/bin/clang
>
> ,etc)
>
>
> The final error I get is
>
> clang: error: no such file or directory: './obj/local/x86/libandroid_native_app_glue.a'
>
> and I can't find this file anywhere.
>
> I assume I was suppose to get this file when I did
>
> $NDK/ndk-build clean
> NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
>
> You should see the following linker error, as the linker can't find the rt_init and rt_term functions you just added:
>
> /home/joakim/android-ndk-r10/sources/android/native_app_glue/android_native_app_glue.c:232:
> error: undefined reference to 'rt_init'
> /home/joakim/android-ndk-r10/sources/android/native_app_glue/android_native_app_glue.c:234:
> error: undefined reference to 'rt_term'
> clang++: error: linker command failed with exit code 1 (use -v to see invocation)
> make: *** [obj/local/x86/libnative-activity.so] Error 1
>
> but I didn't.
>
> If I execute that command in the android_native_app_glue.c dir I get
>
> /opt/android-ndk-r13b/sources/android/native_app_glue# NDK_TOOLCHAIN_VERSION=clang $NDK/ndk-build V=1
> Android NDK: Could not find application project directory !
> Android NDK: Please define the NDK_PROJECT_PATH variable to point to it.
> /opt/android-ndk-r13b/build/core/build-local.mk:151: *** Android NDK: Aborting    .  Stop.
>
> Of course, if I execute it in the project path I get a lot of stuff but not that file anywhere.
>
> I have dried to put
>
> android_native_app_glue.d
>
> in different places but nothing...
>
> Once that is fixed I assume everything should work... but I'm at a loss for what to do next. Any ideas?

If you really want to get it to work, you should replace the old instructions for the app_glue C file with the ones for the D file from the newer ldc/ARM wiki page.  Still no guarantee that it'll all work, as those instructions are written for dmd, while you are using ldc, which hasn't been tried with Android/x86 in a while.

Rather than use Android/x86 (which you are only doing because you think it's easier to test Android apps on Android/x86 in a VM?), I suggest you install the SDK, which comes with an Android/ARM emulator, or run on an actual Android/ARM device, which is what I do.  You can hook a phone or tablet up through USB to your Windows machine and control it better through adb.

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.

Two questions I have:

1. In the command lines present there is a lot of use of `x86`. 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.

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.

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?


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)

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 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). 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?)


Thanks for all the help!

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.

On Wednesday, 11 January 2017 at 03:49:42 UTC, Joakim wrote:
> On Tuesday, 10 January 2017 at 18:48:17 UTC, Ignacious wrote:
>> [...]
>
> 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.
>
> [...]

Ok, well the x86 thing wasn't my idea! It seems I was using the wrong build command for trying to compile the examples.

In any case, I'll just wait until things get working a bit better. I'd suggest you put, in the title of the page, a bit more information. I didn't realize I was looking at an old version(which looks too similar to the new one).

On Wednesday, 11 January 2017 at 21:13:07 UTC, Ignacious wrote:
> On Wednesday, 11 January 2017 at 03:49:42 UTC, Joakim wrote:
>> On Tuesday, 10 January 2017 at 18:48:17 UTC, Ignacious wrote:
>>> [...]
>>
>> 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.
>>
>> [...]
>
> Ok, well the x86 thing wasn't my idea! It seems I was using the wrong build command for trying to compile the examples.
>
> In any case, I'll just wait until things get working a bit better. I'd suggest you put, in the title of the page, a bit more information. I didn't realize I was looking at an old version(which looks too similar to the new one).

I am currently preparing a repository on dockerhub which contains the newest ldc with android support and the Android NDK. While these two applications run in a container you only have to install the Android SDK on your host machine. The dockerfile is in an early state, I will create an anouncememt when it is finished. You can already have a look https://hub.docker.com/r/andre2007/ldc-android/

Kind regards
Andre