On 11/16/2013 06:51 PM, Andrew wrote:
> I think the error was something to do with fibres in Phobos and druntime.

Fibers probably won't work out of the box, but they aren't used anywhere in druntime/phobos so did you get a hello world to run?

On Saturday, 16 November 2013 at 18:03:29 UTC, Martin Nowak wrote:
> On 11/16/2013 06:51 PM, Andrew wrote:
>> I think the error was something to do with fibres in Phobos and druntime.
>
> Fibers probably won't work out of the box, but they aren't used anywhere in druntime/phobos so did you get a hello world to run?

Hello world did run but anything that needed to allocate memory crashed.

Just a thought but most ARM systems, Linux based, used EABI whereas iOS uses an Apple specific ABI so you'll probably need to target each separately. Also there are two variants of EABI hard-float (most common now) and soft-float.

 1. Remove the stupid GC, it doesn't scale anyway
 2. Compile to C or C++

DONE!

WAHOOO

On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:
> * The main program in Android should always be java code, native code
>   loaded as shared libraries. This is implemented in DMD now, but not
>   in GDC. (And IIRC not in LDC either?)

On the 2.064 frontend branch, LDC already uses the same module registration mechanism than DMD, so we are pretty close to working shared library support. There are probably two or three details that still need attention, but I don't expect any major roadblocks. All that is needed at this point is somebody spending an evening or two to iron the remaining kinks out.

David

On Friday, 15 November 2013 at 10:31:40 UTC, Elvis Zhou wrote:
> On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:
>> Also, does dmd have any support for cross-compilation or is it better to stick to ldc/gdc when cross compiling to Android?
>
> A month ago I tried to cross compile a Hello World for Android with ldc on Debian7 x64 with android_ndk_r9 but failed with lots of link errors. One of those issues reveal that qsort is absent from Android stdlib, I get over it by grabbing a qsort.c and it works. Other issues are beyond my knowledge and I'm too busy to continue, hope I can take some time to hack on this late this month.

What did you modify in ldc to try and get it to work with the NDK and compile an Android-compatible binary?

I spent some time setting up the appropriate VMs and looking at the relevant Android dev tools myself.  It appears that the Android NDK uses a lightly patched version of stock llvm/clang 3.3, along with the gold linker.  Their patches are available online:

https://android.googlesource.com/toolchain/llvm/+log/release_33
https://android.googlesource.com/toolchain/clang/+log/release_33

Their llvm is the same as llvm 3.3 until commit ce33750 and clang is the same until commit 20c7d45.  The stock llvm/clang 3.3 have some limited support for Android, not much.  I'm going to start going through those patches next.

Since there are only about 50-100 llvm/clang patches, many of them architecture-specific and so not necessary, this suggests that the Android ABI is not that different from linux.  Although, when I ran ldd from Arch linux on an x86 sample app compiled by the NDK, it said "error while loading shared libraries: /usr/lib/libc.so: invalid ELF header," suggesting there is some difference.  They wrote their own ldd for the NDK, which works fine with their generated code:

https://android.googlesource.com/platform/ndk/+/master/sources/host-tools/ndk-depends/ndk-depends.cc

Turns out I was wrong earlier when I said I'd compile D to pure native, as opposed to a shared library pulled in through JNI, as the former is not possible on Android.  I saw some docs earlier where they said you can write pure native apps now and you can, but I now see that you still have to compile it to a shared library, because they want everything sandboxed within Dalvik.  You provide an android_main function as the entry point from Dalvik into the native app/library, so shared library support and some JNI compatibility are necessary for D to work on Android.

It appears the next steps to get D working on Android/x86 are:

1) Get a basic D "hello world" shared library to compile and run on Android, by modifying dmd to generate an Android-compatible shared library.
2) Get druntime and phobos working as much as possible.
3) Translate the remaining native Android API headers so they can be called from D.

I was hoping to mostly work on 2), but it appears there's some work for 1) that has to be done first.  If anybody else wants to help with 1), you too can take a look at the above llvm/clang commits and let us know what you find.

On Friday, 22 November 2013 at 18:01:44 UTC, Joakim wrote:
> I spent some time setting up the appropriate VMs and looking at the relevant Android dev tools myself.  It appears that the Android NDK uses a lightly patched version of stock llvm/clang 3.3, along with the gold linker.  Their patches are available online:
>
> https://android.googlesource.com/toolchain/llvm/+log/release_33
> https://android.googlesource.com/toolchain/clang/+log/release_33
>
> Their llvm is the same as llvm 3.3 until commit ce33750 and clang is the same until commit 20c7d45.  The stock llvm/clang 3.3 have some limited support for Android, not much.  I'm going to start going through those patches next.
>
> Since there are only about 50-100 llvm/clang patches, many of them architecture-specific and so not necessary, this suggests that the Android ABI is not that different from linux.
Alright, went through all the Android llvm/clang patches and there's little of significance.  They hardcode two clang options for android/x86, -mstackrealign and -msse3, add a few tweaks for ARM, and that's about it.  Most of the patches are for some other NDK work by MediaTek, which don't appear to be used by the official Android NDK.

I was able to compile an identical stripped shared library from the samples just by using the stock clang 3.3 that's installed in Arch linux, once I added the two hardcoded flags in with the rest of the flags their makefiles generate, so you really don't even need to use their compiler, at least for Android/x86.

Next step, get dmd to do the same with a "hello world" native Android app.  I'll update this thread as I go, for anyone who's interested.

On Monday, 25 November 2013 at 10:38:24 UTC, Joakim wrote:
> On Friday, 22 November 2013 at 18:01:44 UTC, Joakim wrote:
>> I spent some time setting up the appropriate VMs and looking at the relevant Android dev tools myself.  It appears that the Android NDK uses a lightly patched version of stock llvm/clang 3.3, along with the gold linker.  Their patches are available online:
>>
>> https://android.googlesource.com/toolchain/llvm/+log/release_33
>> https://android.googlesource.com/toolchain/clang/+log/release_33
>>
>> Their llvm is the same as llvm 3.3 until commit ce33750 and clang is the same until commit 20c7d45.  The stock llvm/clang 3.3 have some limited support for Android, not much.  I'm going to start going through those patches next.
>>
>> Since there are only about 50-100 llvm/clang patches, many of them architecture-specific and so not necessary, this suggests that the Android ABI is not that different from linux.
> Alright, went through all the Android llvm/clang patches and there's little of significance.  They hardcode two clang options for android/x86, -mstackrealign and -msse3, add a few tweaks for ARM, and that's about it.  Most of the patches are for some other NDK work by MediaTek, which don't appear to be used by the official Android NDK.
>
> I was able to compile an identical stripped shared library from the samples just by using the stock clang 3.3 that's installed in Arch linux, once I added the two hardcoded flags in with the rest of the flags their makefiles generate, so you really don't even need to use their compiler, at least for Android/x86.
>
> Next step, get dmd to do the same with a "hello world" native Android app.  I'll update this thread as I go, for anyone who's interested.

Thanks, I'm interested.

On Monday, 25 November 2013 at 11:32:56 UTC, Chris wrote:
> On Monday, 25 November 2013 at 10:38:24 UTC, Joakim wrote:
>> Next step, get dmd to do the same with a "hello world" native Android app.  I'll update this thread as I go, for anyone who's interested.
>
> Thanks, I'm interested.
I just spent a couple hours trying to get dmd to compile a "hello world" app on linux/x86 without druntime and phobos, so I might as well document it here.  After looking at a bunch of old newsgroup posts and some druntime source, I came up with the following foo.d:

extern (C) void puts(const char*);
extern (C) int main() {puts("Booya cuddie!\n");return 0;}

I compiled foo.d with a local, unpatched build of dmd from git as of 10 days ago, dmd compiled by clang++:

./src/dmd -v foo.d -betterC -defaultlib=

No good, it wants an object.d, despite being a better C:

Error: cannot find source code for runtime library file 'object.d'
       dmd might not be correctly installed. Run 'dmd -man' for installation instructions.
Specify path to file 'object.d' with -I switch

So I copied object.di from druntime into the same directory, but it turns out that simply placing an empty file called object.di there also works. :)

Next error, it doesn't link:

foo.o:(.text.d_dso_init[.data.d_dso_rec]+0x33): undefined reference to `_d_dso_registry'
collect2: error: ld returned 1 exit status
--- errorlevel 1

So I checked the symbols from the object file it did build:

> nm foo.o
00000000 t
         U _GLOBAL_OFFSET_TABLE_
         U _d_dso_registry
00000000 T main

It turns out that there's a weak reference to _d_dso_registry for ELF object files, but it was recently made a requirement on linux only.  I got rid of that requirement by changing the REQUIRE_DSO_REGISTRY define to this line in ./src/backend/elfobj.c:

#define REQUIRE_DSO_REGISTRY (DMDV2 && TARGET_RLINUX)

Recompile dmd and foo.d now builds and runs. :) Obviously, this patch shouldn't be necessary if you're not on linux.

Next, getting this minimal app running on Android/x86.  It turns out there is some support for building executables directly in the Android NDK, just undocumented, though the docs are fairly bad generally.

On Monday, 25 November 2013 at 22:32:26 UTC, Joakim wrote:
> On Monday, 25 November 2013 at 11:32:56 UTC, Chris wrote:
>> On Monday, 25 November 2013 at 10:38:24 UTC, Joakim wrote:
>>> Next step, get dmd to do the same with a "hello world" native Android app.  I'll update this thread as I go, for anyone who's interested.
>>
>> Thanks, I'm interested.
> I just spent a couple hours trying to get dmd to compile a "hello world" app on linux/x86 without druntime and phobos, so I might as well document it here.  After looking at a bunch of old newsgroup posts and some druntime source, I came up with the following foo.d:
>
> extern (C) void puts(const char*);
> extern (C) int main() {puts("Booya cuddie!\n");return 0;}
>
> I compiled foo.d with a local, unpatched build of dmd from git as of 10 days ago, dmd compiled by clang++:
>
> ./src/dmd -v foo.d -betterC -defaultlib=
>
> No good, it wants an object.d, despite being a better C:
>
> Error: cannot find source code for runtime library file 'object.d'
>        dmd might not be correctly installed. Run 'dmd -man' for installation instructions.
> Specify path to file 'object.d' with -I switch
>
> So I copied object.di from druntime into the same directory, but it turns out that simply placing an empty file called object.di there also works. :)
>
> Next error, it doesn't link:
>
> foo.o:(.text.d_dso_init[.data.d_dso_rec]+0x33): undefined reference to `_d_dso_registry'
> collect2: error: ld returned 1 exit status
> --- errorlevel 1
>
> So I checked the symbols from the object file it did build:
>
>> nm foo.o
> 00000000 t
>          U _GLOBAL_OFFSET_TABLE_
>          U _d_dso_registry
> 00000000 T main
>
> It turns out that there's a weak reference to _d_dso_registry for ELF object files, but it was recently made a requirement on linux only.  I got rid of that requirement by changing the REQUIRE_DSO_REGISTRY define to this line in ./src/backend/elfobj.c:
>
> #define REQUIRE_DSO_REGISTRY (DMDV2 && TARGET_RLINUX)
>
> Recompile dmd and foo.d now builds and runs. :) Obviously, this patch shouldn't be necessary if you're not on linux.
>
> Next, getting this minimal app running on Android/x86.  It turns out there is some support for building executables directly in the Android NDK, just undocumented, though the docs are fairly bad generally.

Interesting. Johannes mentioned that the main app should always be in Java so it goes through Dalvik. I've done some JNI-D stuff already (only a proof-of-concept command line app though). I wonder what's the best way of porting D to mobile OS's (mainly Android and iOS).